I understand this point very well, but I don't view it as important. Having validation handled separately by an xml schema validation tool (e.g. xmllint) has always worked well for us and isn't much of an additional burden.However, I've already explained that there is much more going on than that, unless you really don't care about the Collada schema. A library that only parses XML doesn't know which nodes are allowed as child nodes, it doesn't know which attributes are allowed on which nodes and it doesn't know about the data types defined by the Collada schema.
It's also important to keep in mind that the schema itself can only validate a fairly small percentage of the information contained in a Collada document. For example, suppose I'm writing a conditioner to convert polygon primitives to triangles in a Collada document. Maybe I accidentally call the <triangles> element <triangle>. With a code generator like you're using, this should show up as a compilation error. In my case, I would detect the error when I attempt to validate the output file against the schema using xmllint.
But what if my polygon triangulation algorithm is wrong? This isn't going to be caught by the additional checking provided by your code generator, and won't be caught by an external schema validation tool. In my experience the great majority of bugs in Collada programs are of this sort. This is why the Collada Coherency Test program was created, and why a huge amount of time and manpower has been invested in developing the Collada Conformance Test Suite. Checking against the schema isn't nearly enough to ensure program correctness.
Good luck with your project. Let us know if you come up with a workaround for the <group> bug in Microsoft's code generator... I'm sure other people would benefit.