Your description of how RFC 5959 works isn't quite right. It is not quite correct to state that RFC 5959 encrypts using AES in ECB mode.
A correct statement is: if the plaintext is exactly 128 bits, then use ECB mode, otherwise use a non-trivial mode of operation found in RFC 3394. In the former case, ECB mode is fine, since it's just a single block of data. In the latter case, RFC 5959 says to use the AES Key Wrap with Padding algorithm as defined in RFC 5649. This algorithm specified in Section 4 of RFC 5649. Section 4.1 of RFC 5649 specifies the key wrap, and explains how it works. It says to use the scheme of Section 2.2.1 of RFC 3394, if the input is not exactly 128 bits (which is the case that will occur if you are storing a 256-bit ECC private key.)
Anyway, a key wrap algorithm (such as specified in RFC 5959) is much better than simple XOR. (If there was no salt, a simple XOR would be insecure if you used it to protect two different private keys with the same passphrase: compromise of one private key would enable an attacker to learn the other private key (since it's just a two-time pad).) More seriously, a simple XOR is malleable and thus would allow related-key attacks on the underlying scheme, as Ricky Demer explains; if the underlying scheme (e.g., ECC decryption) is vulnerable to related-key attacks, this would be a problem.
Better to use a key wrap algorithm. Key wrap algorithms are designed specifically for storing private keys in encrypted form, and there's a reason they use something other than simple XOR.