I agree, but it should still be possible mitigate those sorts of threats without the user needing anything else in thier head (at least more than temporarily :-), even if the password for the negotiation was successfully brute-forced / MITM'd so that a foreign device could initiate a private key transfer, and even if the private key exchange itself was MITM'd.
Perhaps for example using a one-time shared secret either displayed on one device and entered in the other, or entered by the user on both devices as a temporary pass-phrase. This could then form part of a D-H style key exchange, or even be the encryption passphrase as in your proposed model, but only used temporarily while the private key is transferred, so not having to be remembered by the user for a centrally stored copy of the private key.
I appreciate you're probably well down the track on your current model, but it would be really nice to see something like this developed, and ultimately standardised, as like you mention in your manifesto, private key management (and especially transfer and backup) is one of the larger usability barriers to wider adoption of public-key cryptography.
Perhaps for example using a one-time shared secret either displayed on one device and entered in the other, or entered by the user on both devices as a temporary pass-phrase. This could then form part of a D-H style key exchange, or even be the encryption passphrase as in your proposed model, but only used temporarily while the private key is transferred, so not having to be remembered by the user for a centrally stored copy of the private key.
I appreciate you're probably well down the track on your current model, but it would be really nice to see something like this developed, and ultimately standardised, as like you mention in your manifesto, private key management (and especially transfer and backup) is one of the larger usability barriers to wider adoption of public-key cryptography.