Edits: added then removed additional cases that on reflection seem like a bad idea. In fact, this whole line of thought seems like a complicated way to get a bigger nonce, which might be better accomplished with something like XSalsa20 which was designed for that. I will accept the "just use the right tool" answer, but if anyone has anything further to contribute please do.
To prevent possible stream cipher key repetition given unreliable storage, provided only that your RNG works and at the cost of some bytes per connection, start the connection with a random cipher key that is not stored on disk and is used to encrypt the rest of the stream (i.e. as the key for your stream cipher, which might be AES-256-CTR, ChaCha20, or a Keccak based stream cipher).
Questions (assume we have a MAC and any reply will encrypt with that random key and a different, previously agreed, nonce):
Suppose you use a simple shared secret XORed with this random key to encrypt it and have a reliable random number generator. An attacker can then easily get random key 1 XOR random key 2 and encrypted streams 1 and 2, but it seems like this shouldn't help. Are there any specific properties that a stream cipher would need to have or not have for this to be exploitable?
If that doesn't work or you don't trust that your RNG doesn't have some characteristic that might be exploitable with that system, add a random nonce sent before the key and use the shared secret to encrypt the random key (via the stream cipher) with that nonce. Now are there any considerations that would make this system exploitable beyond the need for your RNG to generate a good key each connection?