I guess I must be missing something but for a btree to work, you need to be able to compare the key you are looking for against the values in the internal index nodes of the tree. If the values in the index nodes are actual keys and not some analyzed version of them (which is what I was incorrectly calling the hashed key) then it seems there would be a way to construct the keys in the db by only visiting the index nodes. Since the number and size of these nodes shouldn't be affected by the amount of data in each row, I was a little surprised to see the performance change that I did. Obviously I'm missing something about the implementation but that was my reasoning and where my comment came from.
Yes, your solution is the one I have in mind. The concern is maintaining coherency and that's why I was hoping to avoid it.