There seems to be two distinct types of attack for that attack vector:
(1) bypassing OS logon screen by patching in-memory code
(2) stealing password or encryption key for already-mounted encrypted volume
But bypassing or stealing password or key for cold, non-mounted volume is impossible: for example, TrueCrypt volume is mathematically indistinguishable from /dev/urandom output until exact password is provided.
Well, I'd imagine something like a laptop hooking up to the target machine, over both USB and firewire (or something like it). The USB interface would act like a disk, holding an executable or two you'd like.
Walk over the process list in memory, and find one that's got good privileges but stays asleep. Patch its code to call mount (anywhere's fine, maybe in the heap, or if it's asleep in sys_read, in the destination buffer), alter the saved IP in the task table to the mount call, and (this may be the tricky part) move it to a CPU's ready-task list.
After mount, play the same trick to run an executable, and change it's UID to root. Hell it can just spin in a get UID/sleep() loop until it's ready. Then you've got all of root-userland to do what you need. That can include installing keyboard sniffers that save the last kilobyte or so, which is saved or transmitted when the right entry point into the encrypted-mount path is hit.
But bypassing or stealing password or key for cold, non-mounted volume is impossible: for example, TrueCrypt volume is mathematically indistinguishable from /dev/urandom output until exact password is provided.