In general, this is a bad idea. I won't give you any concrete attacks, but will try to explain why you shouldn't do this. In general, if you want to encrypt a key then you should do it using a secure mode for this purpose. (One is the SIV mode of operation. Another is just to use GCM or CCM.) First, I want to stress that you should always use an authenticated encryption mode, by default. Next, the problem of encrypting with ECB is that it has ramifications that can be problematic. In order to see this, denote by $(c_1,c_2)$ the two blocks encrypting the key $k$ which is 256 bits long. Denote $k=k_1\|k_2$ where each $k_1,k_2$ is 128 bits long (Thus $c_1$ is an encryption of $k_1$ and $c_2$ is an encryption of $k_2$.) Now, given $(c_1,c_2)$, it is possible to replace the two blocks of the encrypted key with $(c_1,c_1)$ or with $(c_2,c_2)$. If an attacker can get some plaintext/ciphertext pairs with $(c_1,c_1)$, then it can learn $k_1$ in time $2^{128}$. It can then do the same with $(c_2,c_2)$ and the result is that the entire 256-bit key can be learned in time $2^{129}$. Now, $2^{128}$ is beyond the capabilities of what can be done. However, if you are using a 256-bit key, then you clearly think that $2^{128}$ is not enough of a margin. By using ECB, you have reduced the security down to $2^{128}$. Beyond this, if you can get encryptions under this key, then you can play around to get encryptions under $k_1\|k_2$, $k_2\|k_1$, $k_1\|k_1$ and $k_2\|k_2$. These are all related keys and there are weaknesses to AES under related key attacks. Even if we don't have a concrete attack on this, it is certainly a threat that should not be ignored.
Bottom line, there is no reason to encrypt with ECB so don't do it. If you do, you certainly run the risk of significantly reducing the complexity of the attack. Make sure that you use an authenticated encryption mode (if you encrypt with CTR then you can flip bits and once again get a related-key attack).
