The memory usage is primarily storing the UXTO in memory. The memory pool is also kept in memory but it is much smaller than the UXTO. You could probably reduce the memory footprint with some "intelligent" caching system scoring each output based on the likelihood it will be in the next transaction (i.e. the unspent output from the coinbase of block2 is probably not going to be used in the next tx so dropping it from the in memory cache won't be an issue).
Remember reads from disk are very slow (compared to memory) and you can't validate a transaction until you lookup the outputs. If none of the unspent outputs are in memory well you have now made 100% of tx validations requiring a round trip to the disk. Right now throughput of the network is slow enough that you won't fall behind however for bootstraping a new node it is going to be painfully slow.
LOL you began answering my next question before I posted it.
This all makes sense to me then, and explains why Cypherdoc's bitcoind node uses so much RAM: it is mostly to permit fast look-ups from the UXTO. If the UXTO can be organized and stored efficiently on a SD card, perhaps with the help of some intelligent caching system like you said, this might work.
(I also think people are underestimating how fast SD cards (especially nowadays). SD cards do not force a file-system like FAT, they are basically just an SPI-interface to a huge array of flash. So I can read small blocks out of flash with an SPI command to address the memory I want and then clock in even short blocks of data at tens of megabytes per second. There is perhaps less overhead here than it may at first appear.)