Is this a secure method of encrypting with authentication?
The system you described—essentially, sign-then-encrypt with ECDSA and ECIES—is vulnerable to the following attack:


Alice sends Bob the signed-encrypted message ‘The deal is off.’
Bob removes the encryption layer, getting a signed message from Alice saying ‘The deal is off.’
Bob re-encrypts the message to Charlie.
Charlie verifies the message and thinks Alice has canceled the deal.


The problem here is that the message that Alice signed didn't specify a recipient.  The same attack applies to practical systems like OpenPGP and S/MIME, as noted by Don Davis in 2001.

The mere use of signature is also vulnerable to the following attack:


Alice types ‘what a basket of deplorables the voters are’ into her phone, but accidentally sends it to a journalist Jamal instead of her running mate.
Jamal now has a signed message from the political candidate calling her constituents deplorables which he can show to anyone.
Bob wins the election.


The problem here is that anyone can verify Alice's message, because signatures by design provide third-party verifiability.  (The respect Alice has for the voters may be another problem, and the respect Bob has for democracy, rule of law, and journalists, yet another problem, but let's not make this situation too real lest someone get diced up with a bone saw.)

There's a much simpler system, which is actually what Diffie and Hellman suggested in their seminal 1976 paper.  Assume Alice has published her public key $A = [a]P$ in the telephone book, and Bob has published his, $B = [b]P$.


To send a message $m$, Alice looks up Bob's public key $B$ in the telephone book and computes $k = H([a]B)$ to use with an authenticated cipher $E$ to send the ciphertext $E_k(m)$ to Bob.
On receipt of a ciphertext $c$, Bob looks up Alice's public key $A$ in the telephone book and computes $k' = H([b]A)$ to open the message $m = {E_k}^{-1}(c)$, or drop it on the floor if verification fails.


If the telephone book hasn't been tampered with, $k = k'$ so Alice and Bob can communicate.

If Alice wants to save time for many messages to Bob, she can cache the shared secret $k$ and reuse it many times; likewise Bob.  The only overhead is the authentication in the authenticated cipher $E$.

Bob can't forge a message from Alice to Charlie because Charlie has a different shared secret with Alice.  Jamal can't cryptographically prove to anyone else Alice sent an incriminating message, because any ciphertext that Alice could have made, Jamal could have made too using the same shared secret.

This very simple protocol—and the protocol you proposed—has another issue: if Alice's long-term key $a$ ever gets exposed, anyone who learns it can decrypt any past messages Alice has ever exchanged with anyone.  Modern protocols also do key agreements for each conversation like TLS, or each message like Signal, so that they can quickly erase the keys that would allow a network eavesdropper to decrypt past messages.  If you want a bespoke protocol in an application for which existing systems like TLS are unfit for some reason, you might look into the Noise protocol framework and the Noise Explorer, a tool to automatically verify security properties of custom instances of Noise.