On a general basis, you want to keep encryption and signature keys disjoint, because they tend to have distinct life cycles. In broad terms, an encryption key should be escrowed, because loss of the private key implies loss of the data which is encrypted relatively to the public key. However, a signature key must not be escrowed, since the proof value of a signature comes from the control of the private key by only the key owner. See this answer for a more detailed discussion.
It may happen that your specific situation may tolerate unescrowed encryption keys -- for instance, your encryption key (which you call "key exchange key") is used only for establishing short-lived session keys, which are not used to encrypt data, or such that the encrypted data is promptly decrypted on the other side, and never stored encrypted. I.e., your key exchange key is used to establish SSL-like tunnels, not to send encrypted e-mails. In that case, the one remaining problem is about interactions between the key exchange algorithm and the signature algorithm: could an attacker break a key exchange by having you emit some signatures which use the same private key ? As @CodesInChaos suggests, it is plausible that using the same private key for ECDH and ECDSA is safe, but the Devil is in the Details: unless there is an explicit security proof with the specific algorithms you are intending to use, I would advise against it.
What you can do, and is safe, is to store a master key K, and dynamically derive you encryption private key and your signature private key from K, with a suitable PRF (e.g. HMAC_DRBG).
