You ask very good and subtle questions. We fully understand that although the encryption itself uses a 128 bit key, individuals' master passwords are never that strong in and of themselves.
What Bruce Schneier talks about in the article is addressed by our use of PBKDF2 with 1000 iterations.http://en.wikipedia.org/wiki/PBKDF2
The master password (or a hash of it) is not used directly to create the decryption key, but goes through 1000 iterations of a deliberately slow process that creates a wider key. This dramatically increases the cost of trying a dictionary attack on the master password. Along with this the master password is appropriately salted also to make "pre-cooked" dictionary attacks impractical.
The derived key itself is not use to (de/en)crypt your data, but instead is used to decrypt a truly random decryption key stored in your keychain. This allows people to change their master password without all of their data needing to be decrypted and re-encrypted. The Agile Keychain design also means that the smallest necessary bits of our data are decrypted to fill a form, not the whole keychain.
One thing to note is that our Login Bookmarklet feature (used by some users to have access to 1Password in otherwise unsupported browsers) does not use PBKDF2 or other password strengthening, which is why we recommend that users only use that for low security passwords.
String recovery from memory techniques are harder to thwart, although we do follow recommended practices from the security community. Decrypted material or keys are never explicitly written to disk (and we recommend that users use encrypted swap) and we try to keep that material in memory for as short amount a time as possible, while still allowing users to set how frequently they are prompted for their master password. Naturally some balance is involved here. When the decryption key is stored in memory, it is deliberately obfuscated so that even if the string were somehow made accessible to other processes it wouldn't reveal much.
Of course if an attacker has complete access to all of the memory on your computer all the time, there is nothing that can be done to prevent a breach, but we do take the steps that are within the power of our unprivileged app (1Password runs with ordinary user privileges) to make things harder for an attacker.
I hope that this helps answer your questions. What I want to communicate most strongly is that we actively follow developments and discussion within the security community and seek to implement their recommendations. As you may know, we actually don't have any encryption code in 1Password proper, but instead call upon the OpenSSL libraries. This way we use the tools that have had the most thorough review possible for the guts of the encryption.