|There's more than one way to do things|
The Pragmatic Programmer discusses code generation fairly briefly. The two types it mentions are passive and active.
Passive code generation is like a wizard -- you feed some information to an engine which creates lots of code for you, but then the relationship ends. You modify the generated code as you wish but any future improvements to the generator aren't reflected in already-generated code.
Active code generation is far more interesting. A typical use is when you have an authoritative piece of information (like a database) from which you can extract metadata. Using whatever language you like you can translate the metadata into classes, relationships, metadata objects, schemas, unit tests, etc.
I discussed a system I've developed (in Perl of course, using the Template Toolkit) to generate lots of Java code at YAPC 2003 (slides are online). I hope to write up a more formal article in the near future because it's an interesting process that many OO folks frown upon.
As perrin mentions code generation is frequently a code smell -- if you try to get your system to do too much, or if you make it too difficult to customize the generated code (through parent classes or other means), or if the generation is difficult to integrate into your normal build process (takes too long, cannot invoke without jedi mind tricks, etc.), or if the system forces a certain type of development on you.
But keeping all these things in mind code generation can be an amazing tool. IME database intensive systems where the schema changes often (hey, it's agile!) can benefit greatly from a metadata-driven generation system using the database as the authority.
From my fairly brief exposure Herrington's book is very good. Try to get past the Ruby-isms and focus on the core ideas and, importantly, the pitfalls.