Actually just reading through your response again.

"If a mining pool doesn't see the second signature in time, what happens when they eventually include the transaction in a block (after X blocks have occurred)?"
If the transaction has not being included after delay + validity period blocks it should be disguarded. So for example if you had a 36 block (6 hour) delay wallet you could also have a validity period, so that if it was not included within the subsequent Y blocks it would be marked as invalid.

"How would this be different from a mining pool refusing to honor the second signature and including the transaction in a block (after X blocks), or would it be different?"
So I think you talking about a mining pool colluding with the hacker? If this did happen, you would be no worse off than today. But its fairly unlikely.

"Couldn't an attacker eat up all of the memory (or disk space) of the mining pools by generating these transactions as fast as they can so that the pools need to store millions of transactions that aren't ready to be confirmed, and then transmitting the "cancel" signature before the deadline?"
The 'cancel' action could consume a transaction fee to prevent this abuse?