I still don't understand your desire for a hash, especially considering (as already stated at other places in this forum) that you don't gain any entropy by subjecting a PW to a deterministic function like a hash. So, when decrypting your ciphertext, you will be as secure with a H(key) as with (key), thus you might as well just memorize a good long passphrase + a random string for a good measure. I strongly feel that with such complex requirements and somewhat obscure thoughts one needs to meet face-to-face to really understand the nuances of the desired application.

With that said, I will now attempt to propose an algorithm that you may find useful to whatever you are trying to accomplish. It is not really a hash, but it may hopefully provide the mechanism you are looking for. I am using your terminology here - "key" as the input string and "passphrase" as the output string:

(Note: I will list the decryption phase only, working against an adversary. Encryption would be similar, but can be computerized as stated in the question)

###Initialization:###

• Put a square matrix of random characters, 16 rows by 16 columns, totalling 256 chars, on a piece of paper
• Memorize a good key containing 2 distinct logical parts with equal length, e.g "Johnny%rides || yellow+zebra" (Alternatively, memorize 2 separate keys of equal length). I use here a short weak key just for demo purposes.
• Memorize one random string (preferably containing some high ASCII characters e.g. foreign currency symbols)
• Learn and memorize the 7-bit decimals (or hex) ANSI equivalent of the 95 char sets (I assume you use the English language for your passphrase). Easy to do since they are sequential (can put the full ASCII table lookup on paper)
• Learn and memorize the 7-8-bit decimals (or hex) representation of the characters in the random string (can put the full extended ASCII lookup table on paper).

###Decryption (doing a streaming OTP + substitution):###

• Mentally split the key into its 2 distinct logical parts e.g Part A: "Johnny%rides" and Part B: "yellow+zebra"
• Mentally take one character, at the same position in each Part, and convert to its hex equivalent. e.g. convert "J" and "y" to 0x4A and 0x79 respectively. (it might have been easier to memorize the decimal equivalents, so in that case you should also go through the mental step of decimal -> hex)
• Mentally take the hex value of the character of Part B, namely 0x79, and use its 2 hex elements as a (x,y) index into the written random table. Mentally pull out the random character from the cell and convert it to a hex equivalent.
• Mentally take the hex value of the character of Part A, namely 0x4A, and perform XOR with the hex representation of the pulled cell value. In essence, doing OTP encryption between Part A of the key and a random value.
• Use that hex value as the first character of your desired passphrase, writing it down and freeing your brain from remembering it.
• Repeat the process with the next character of each part of the key, but with each successive character you need to increment the row from which you pull the random cell from, to thwart frequency analysis due to english words which are present in Part B - the index into the random table.

The above process requires minimal memory and mental load. When you are done, you will have your full passphrase. You can increase the size of the passphrase to double (or more) your Part A size by adding to each pulled cell value another cell value, say selected by a "knight move" from the first landing cell - as in a chess game.

###Application Notes:### You can increase security if you prepare larger random matrix, and use 2 successive characters of Part B (mod table size) as an index. Also, if practical, you should prepare several random tables and use them in succession - each associated with a different key. The one random string you initially memorized can be used in a creative way - as an another index into the random table, concatenating or XORing with the results due to Part A etc.

Caveat: I hope that what I proposed here is to some extent what you were looking for. I haven't spent time analyzing the cryptographic strength of this proposal. It may have sever flaws, but this is the best I could come up with at a reasonable time. Before putting it into practical use, you must evaluate its security, deficiency and usefulness.