The part of this answer that talks about key storage is at the end, the first part is about implementing a cascade.
There are 2 main methods for cascading block ciphers, inside of the mode and outside of the mode. Within the encryption you have your mode of operation, and you have your block cipher cascade. The first cipher in the cascade will be considered the primary cipher.
Inside the mode means replacing the block cipher inside the mode with the cascade. In this method there is the single mode of operation wrapped around the cascade. The non primary ciphers essentially act in ECB mode on the ciphertext of the primary cipher, and the ciphertext of the final cipher is the ciphertext of the mode's inner cipher.
Outside the mode means you encrypt the plaintext with each mode (and each cipher) in sequence. This allows use of multiple modes, which can either have a security or performance advantage (or both, or neither). For example, the output of AES_CFB can then be encrypted with Twofish_CBC.
Depending on the target platform and development language, either method may have an implementation advantage. Certain modes of operation such as CTR or ECB are parallelizable, whereas CBC and CFB are note. CTR also allows encryption of lengths that are not a multiple of the cipher block size without using padding or CTS. The method Truecrypt uses is optimized for filesystem encryption, and using that method may not meet your requirements (which are not specified). AES also allows high speed timing analysis/DPA resistant implementations on modern processors with AES_NI instructions.
Cascading has not officially been given anyone's seal of approval, but it does have an allure that a single cipher may be completely broken and your ciphertext remains secure. For the actual security of using it, see the answers here: Combining multiple symmetric encryption algorithms - implications? I tried not to talk about how to implement in my answer, as it was not part of the question like it is here, but the security implications are quite relevant.
As for the main point of the question, how to store keys, you would do it the same way as any other cryptosystem, you are just storing more key data in this case. Standard methods include a high entropy unguessable password hashed with a KDF to generate key data, or encrypting the keys using an asymmetric algorithm. The strength of the KDF and asymmetric key size should be at least as strong as the expected security of the cascade. (256 to 768 bits with up to 3 AES candidate algorithms). In your example a password known to both parties is used to generate the keys, so there is no storage of keys, it is generated from hashing that password in some method that generates enough bits.
My personal recommendation for balanced speed and security would be to use AES128_CTR first then encrypt with Twofish256_OCB3. This requires 384-bits of key data, which can be generated using a SHA384 or an appropriate key derivation function, but it is better to use a strong random source if possible. Getting the keys to the recipient securely is a whole different problem.
