An interesting approach might be to take a few example modules with which you are not familiar, throw away the author's documentation (the pod that is, not the comments), and then try to write the documentation for the module based on the code and any comments.

Interesting idea, a little on the insane side, but nice idea. You might even want to just find a module with little or bad documentation, and email the author to see if you can re-write it for them.

Another good way to get to know a module is to work on it's test suite. The Phalanax project is a great place to do this. I spent a week or so a little while ago working on modernizing the DBI test suite, and in the process learned a lot about how that module is architected.