Jeremy Miller's perception of generated code reflects that of many users:

...I stumbled into the generated code for a strongly typed DataSet this morning.  You know the orange bars that ReSharper puts into the vertical scroll bar to denote warnings in the code?  In the DataSet code it looked like a solid bar of orange sherbert. 

...my experience says that generated code is usually of atrocious quality and lacking in readability.

The comments show a more balanced view: if the developer who wrote the generator is rubbish, the generated code will be rubbish. But if he's good, the generated code will be better than the average mix of developers would write by hand -- plus of course you get it with much less effort. It's a sad indictment of most generators from IDE wizards and fixed CASE or UML tools that the quality of their generated code is so low.

In his comment, Frans Bouma makes a good point which is often forgotten: to get good output, the input to the generator needs to be good, as well as the generator itself being good. That's one of the benefits of DSM over standard code generators or textual DSLs: there's a lot more control over the input. A good DSM language and tool will prevent illegal input, and even guide the developer to creating good input.

Mind you, many first timer DSM solution creators do tend to go too far with adding rules and restrictions, trying to prevent the modeler from doing anything that they themselves can't immediately see as useful. This just leads to frustration for the modelers, and more work for the metamodeler later as he has to unpick all the needless red tape. A good language and tool shouldn't be bureaucratic and nitpicking; give the modelers good structures and possibilities, and they'll mostly make good use of them. Littering the language with barbed wire and electric fences won't stop all possible errors that bad developers could ever come up with, but it may well stop some ingenious and efficient uses that the good developers would invent.