I would expect the strategy you have in mind to be more useful to apply at the filesystem level, so that it's not in Postgres altogether. (Ala "Stacker", remember DR-DOS?)
The relevant bit that seems to describe fairly aptly why what you are suggesting is unlikely to turn out well:
"Some operating systems implement compression at the file system level. Files are typically divided into fixed-size blocks that are compressed into variable-size blocks, which easily leads into fragmentation. Every time something inside a block is modified, the whole block is recompressed before it is written to disk. These properties make this compression technique unsuitable for use in an update-intensive database system."
The principle described is as applicable to Postgres as it is to InnoDB, and is as applicable to attempting to compress disk blocks from within the database as it is to apply it at the filesystem layer.
You should avail yourself of the code on TOAST: ./src/backend/catalog/toasting.c ./src/backend/access/heap/tuptoaster.c ./src/include/catalog/toasting.h ./src/include/access/tuptoaster.h
