Actually, I think your posting contains two different questions, let's start with the simple one first:
are there any good tools or methodologies for peer reviewing code documentation?
I don't think there are "special tools or methodologies", because there is nothing special needed. Peer reviewing documentation works like any other kind of proofreading - you give the documents to the reader, he reads it, adds comments or suggestions for changes and finally you discuss the suggestions. That's all, it works with any kind of documentation technology (of course, some technologies make proofreading and commenting a little bit easier, but that does not change the general methodology).
Many devs that I work with will put up wiki pages, javadocs, etc, but most of the time, unless someone else needs it right away the docs will go unnoticed and unreviewed.
That is actually your second question - in other words "why do lots of people do not take notice of separate code documentation, or don't care for their quality?"
I think this question has been discussed in-depth here on this site, as well as in lots other places. It is a very broad question, but it all boils down to "is additional documentation really worth the effort?" And as long as the answer is not clearly "yes", don't expect to get a different answer to ""is it really worth the effort to review it?"
My personal opinion about this is that any team which is responsible for a certain product has to find the amount of documentation, and the correct abstraction level for the documentation that works for the team and the product. And once you found that, and the team sees a lot of value in that docs, the demand for reviews will arise by itself.