However, I'm wondering, if I change the AES key in the field, but keep the same "encrypted key" and nonce, could I use the same procedure as above to generate a new ECC key?
Let me restate this: you have a ciphertext (nonce + encrypted key) that decrypts with AES key A to one value (which you will use as an ECC private key). You are asking what happens if you switch to key B; will you decrypt to another value (that will be also be usable as an ECC private key).
Let's get the first concern out of the way: any integer can be used as an ECC private key. It's not like an RSA private key (whose representation usually has considerable structure), instead, the only values that don't work as private keys in ECC are values that happen to be a multiple of $q$ (the order of the generator of the curve), and the probability of picking one of those values randomly is miniscule.
On the other hand, depending on the AES mode of operation, you might not get an integer. Some modes of operation (for example, GCM) will (with high probability) result an error if you use the wrong key. Other modes of operation use padding; unless you turn that off, the decryption may result in a padding error (which will either give you no key, or possibly a smaller key than usual).
In this is a property that you want, you want a mode that avoids both those scenarios - that is, on any decryption, it always returns something (and doesn't truncate the result because of a misinterpreted padding). Counter mode is one obvious choice (as it can be used without padding), as is unpadded CBC. Actually, it strikes me that this is one of the rare cases that unpadded ECB mode would work.