Let's define a good ORM though.

A good ORM should be able to handle a database designed for a different application, normalized to 5NF or BCNF, using composite primary keys, composite foreign keys, and other solid db design concepts, and be able to reliably generate queries to bridge the gap, and should do so where sets of objects are required in a way that does not unduly burden the database with small queries that could be consolidated.

That's a hard problem. There are some ORMs that come pretty darned close if not there. Many more, in my experience fall well short.