We can create a new "contact engine" for QtMobility as it is. I had to play a little bit with the "maemo5" backend and end up creating an "alternative version" of it to be able to use the latest code from the repository. I think would be pretty simple to start with the code that you created for TOR and create a QtMobility Contacts backend for google contacts. Allowing to merge these contacts with a different engine (or the local contacts database would be a different issue all together). Off topic: I wonder why we still don't have a qt mobility backend based on sqllite. If we could have a "database" that would cache/aggregate contacts information from different backends it would be easier to deal with syncing/merging. I guess that is the idea with the current "contacts database" but I would prefer a cross platform implementation where we could create backends that deal with the data (sql) directly.
Getting your code into a new backend is a good first step but I think for you to have this contacts integrated into the "standard contacts database" won't be as much fun. You will have to make sure to add the "google account" field (preferably as TOR would have them) and I would guess, in order to make efficient to synchronize, you will need to create a cross-reference table somewhere else.
epage: does TOR store the google contacts on the "user contacts" database? I would imagine it does because I was able to merge them with my other contacts. I assume I just don't see them when TOR is disabled, right?