Yes, however I believe that the reason is a bit subtler than what fgrieu gave.
From your question, I don't believe that you're actually doing standard ECIES, but instead something such as NaCl's cryptobox (which is a variant).
With standard ECIES, to encrypt to the public key $A$, the encryptor selects a random value $r$, and generates the ciphertext:
$$rG, \text{Encrypt}( rA, \text{Message} )$$
In contrast, with Cryptobox, Bob doesn't select a random value, instead, he uses his own private key. That is, to encrypt to Alice's public key $A$, he will take his private key $b$, and produce [1]:
$$\text{Encrypt}( bA, \text{Message} )$$
This is effectively ECIES (with the $bG$ value implicit; that's Bob's public key). As Bob's private key is random (independent of Alice's keys), this is secure as long as standard ECIES is secure [2].
However, this raises the question: what if Alice encrypts to herself? Will that remain secure? That would not immediately follow from the security of ECIES, as Alice's private key is not a random value independent of Alice's public key.
In this specific case, it turns out to be secure. Specifically, the problem of "given $G, aG$, compute $(a^2)G$" (which is needed to decrypt Alice's message to herself) is just as hard as the general problem "given $G, aG, bG$, compute $(ab)G$". That is, given a way to solve one, you can solve the other.
[1]: Actually, I believe Bob includes a nonce to make the encryption nondetermanistic; that's not important for this explination
[2]: Actually, we need to assume that this construction doesn't leak information about Bob's private key, and that ECIES is secure even if you repeat the same random value; that's actually the case.
