Agreed. Only doing operations involving transferring the key to RAM when the user is present should mitigate it, perhaps with a prominent WARNING dialog showing when memory is vulnerable, and overwriting the memory locations used for the key when done.
Truth be told, if RAM is a security liability for the few seconds it takes to enter the password and derive the key, then you can't give any security guarantees whatsoever no matter what algorithm you use, scrypt, PBKDF2 or any other.
It's not like you can punch the password into the CPU directly, you need to use some sort of input device which has drivers which keep state in RAM, use DMA and IRQs etc. Any attacker capable of reading RAM during this phase is also capable of sniffing the password characters as they are typed on the keyboard.
If we keep thinking on tine slices of time, even a shoulder surfer attack (with cameras in case of a pass-phrase :)) can be a problem... We are not talking about how to prevent a break during the time when the user is typing the password (torture attack is still a valid one and no technology will ever prevent it). But I like good ideas: once mounted, the password cannot be retrieved as it's stored in the chipset itself... I don't know if the test pins on those processors will make this vulnerable but it worth a try-catch. And if Windows go into sleep/hybernate, you loose the password and have to mount again to restore operation. This is possible as we mount the driver as a removeable media.
