In case you haven't already, you might be interested in this related thread; specifically it describes a script that might be useful to your purposes.
Although arguably a custom ODK Collect (and Aggregate) - with geopoint/geotrace/geoshape widgets which spit out compatible KML instead - might be the most user-friendly solution to your users, its highly unlikely to make it into the main code, so you'd end up having to maintain a custom fork going forward. And you'd have to re-write all @ggalmazor's GeoJSON export code. Similarly, a custom geo-to-kml() XPath extension function is probably too specific to justify adding to main; it would require all ODK clients having to add it to their XPath library, eg Enketo uses a different lib than Collect (so again you may end up having to maintain a custom fork). But perhaps if there are other standard XPath functions (eg tokenize()?) that could be used (in conjunction with translate()] to do the translation, these might be more amenable to add in support for.
Something along these lines may be your best bet; that is extending current export formats to include an export to Google Fusion format. This keeps the (ostensibly redundant) additional KML format out of the core Collect/Aggregate data flow.