Ideally we'd want such pass-phrases to have 128 bits of entropy, although I suspect just getting to 64 bits would be a big improvement on most general password/pass-phrase schemes (Does anyone know of research into how stretching a 64 bit key to 128 bits affect real-world crypto-systems? Assuming a "slow"/"good" stretching/key derivation scheme, and the use of a salt, I suspect it might be "good enough").
Now, some napkin math: The English alphabet consists of 5 vowels and 21 non-vowels; we can generally start words with a combination of the two, and some words (like "two") start with a sequence of two non-vowels. 5 * 21 = 105, with another 23 combinations we can reach 128. That's 7 bits for a single word out of a list of 128, identified by it's first two letters. To reach a minimum of 64 bits, we need 10 such words, or perhaps two sentences of 5 words each (Note that there is little help in captilaization here, that single bit doesn't really move the needle on the number of words we end up needing -- considering the difficulty of remember which of a set of random letters are capitalized).
Creating word lists of 128 words is quite easy - we could have some lists of substantives, verbs, adverbs etc - it might even be possible to find words that rhyme. So we could probably construct pass-phrases like: "[The] small red car drives quickly", "huge scary horse hides sadly" -- which we can input/verify/use in their "short form" encoding 70 bits: "smrecadrquhuschohisa". To get through password "security" tests, we might say that the first letter is capitalized, and a period added on the end (possibly we should throw a number in there as well, but hopefully three letter classes are enough for most "checks"): "Smrecadrquhuschohisa." or "1Smrecadrquhuschohisa."
Note that the point here is that the words can be generated just as we generate symmetric cipher keys - from a random 70 bit number -- and are just as secure (or insecure) as such keys are. The rule-based capitalization and punctuation doesn't add any entropy -- it's just there in case we need to get accepted by legacy systems.
Also note that, even this simple scheme, requires a lot of typing for just 70 bits. At 7 bits per word, we'd need 19 words to go beyond 128 bits - which probably means it would be just as well to go for four five-word sentences.
Now, the point of all this, is that if you want a poem that lets you remember 128 bits of random data, you have some work cut out for you, if you want this system to be based around simple generating rules, that are obviously without any bias (no more bias than what you find in generating symmetric (session) keys).
I've been playing with this idea for a while, but so far it seems ~64 bits is a likely "wall" for easy to implement correctly, in a way that's easy to use.
Other options is to use a graphical input - with emoji or images in a grid, possibly with the added factor of colour (eg: red/white, blue/white, black/white etc) - but 128 bits of information turns out to be a lot to encode!