This is just my purely subjective personal opinion but if I had a wallet with $100,000+ in it I would store it on a computer that had complete air gap security - not even an RS-232 link to an Internet-connected computer. I would want the ability to create offline transactions by hand-keying in the source and destination addresses and would broadcast the transaction by having the offline computer print a hard copy that another computer could scan in and upload to the network.
Well you can do that with Armory. It just might be quite a bit of handwriting (I think some transactions can be up to 10kB)...
However, I had considered the possibility of using webcams and QR codes. But that will turn into a mess of wires and complicated interfaces to deal with multiple QR codes, etc.
QR codes should definitely be doable for transmitting transactions. I started writing a wrapper protocol in Java using QR codes (and web cams for reading them) last year. I got as far as creating a proof of concept, or close enough anyway. I never fully developed it since I found it difficult to setup a testing environment that I was happy with and I anticipated a lot of problems related to generating the offline transactions that I didn't want to tackle. Most of the code has been publicly available for quite some time now. In fact I stripped out the screen capture/reading capabilities and offered it to Jim as a reference implementation for a feature he was working on in MultiBit at the time. I'm not much of a programmer so it may or may not have made it into the code base. He did encounter some Java platform limitations regarding window transparency using it on Mac as I recall.
I believe the QR code spec allows up to about 2,000 reduced ascii characters (not bytes) per QR codes. Base91 appears to be the ideal encoding for QR codes. I know BeeTag on my Nokia 5230 had a software limitation of 250 characters. The smallest BitcoinJ transactions at the time tended to be a bit bigger than what my Nokia could handle, but that is solved easily enough by splitting up the tx across multiple QR codes, using as many character allowed by the spec, and/or storing some basic metadata in the QR code. In any case it would be a lot faster than typing. I estimate my reference implementation could handle transactions up a little over 64,000 bytes.
