Elliptic Curve Integrated Encryption Scheme (ECIES) is a type of Integrated Encryption Scheme (IES) that uses Elliptic-Curve Diffie-Hellman (ECDH) key agreement to establish an ephemeral data key (rather than a session key) which is then used to encrypt data using a symmetric scheme. It uses an ephemeral key during the creation of the ciphertext, for which the public key is stored with the ciphertext. Usually, the receiver / decrypting entity has got a static key pair for which the public key needs to be trusted by the sender / encrypting entity.
ECIES can of course be used for authentication of the receiver: you could encrypt an ephemeral key using the data key, send it over, and if the other party is able to decrypt then you have authenticated the receiver. Of course, the receiver must still show that it now has the authentication key to e.g. create a MAC over a message known by both parties. In the case of TLS you would basically be replacing
RSA_ ciphersuites that perform RSA encryption with
ECIES_ ciphersuites that perform Elliptic Curve encryption.
That sounds great, but hold on: both parties now first have to establish an ephemeral data key, to encrypt an ephemeral authentication key. It would be much easier to simply use the data key for authentication. If you'd do that then you're back to Diffie-Hellman key agreement. So basically it would only be useful if normal DH key agreement can - for some reason or other - not be directly integrated in the protocol.
This is an explanation by example that differs from an earlier, more concise one given here. That one focuses on the session key derivation, this one is more about the possible entity authentication.
There are several versions of the DH key agreement that allow authentication. Most possible schemes are documented in NIST SP 800-56A Revision 3: "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography", chapter 6.
Basically you need a static DH key to perform authentication which then can be performed by validating a MAC created using the derived key. So the "1S" scheme (S for Static) is able to authenticate one entity, and 2S schemes are able to authenticate both entities (I'll skip over multi-entity key agreement, for now, keeping it at a single pair).