With a NoSQL database, you are able to more directly map your application data to your datastore. Object-relational impedance mismatch isn't any issue, and as such you can create a more direct relationship between your application's class design and the schema of your NoSQL database.
Example, for a hypothetical Player class, which may contain complex data structures, attempting to store that data into a relational database would require a complex database schema, as well as complex wrapper classes in the game's actual code base. Almost all of this complexity is removed when storing into a NoSQL datastore. You can develop Entity groups that mirror the structure of your game's Player class.
Using NoSQL for MMOGs is still a fairly new concept, because you do lose complex SQL querying which are critical for game designers, and most NoSQL datastores don't offer transaction support, which is another major omission. That said, be sure CouchDB meets the needs of your game, as choosing the wrong database solution could have dire consequences.
I recently wrote a blog post about why we chose to use Google App Engine as our database solution, and I'll be delving deeper into our actual application design and implementation details in later posts, if you want to keep an eye out for them. Even though we are not using CouchDB, I think you may still find it informative, or at least entertaining ;)