None of those schemes define any formatting
You don't needs any input formatting for ECDSA, you just feed your plaintext into the hash function.
You only need a formatting if you want to exchange public keys and / or private keys (I'll count "with yourself" in the future as exchange here).
As far as ECIES goes, the situation is a bit more complicated. There are standards defining formats for ECIES (so you can decide how the payload was encrypted for example), but they haven't seen wide adoption (may be due to the pay walls) yet. Refer to this paper for a comparison of the standards.
EC-ElGamal isn't widely used and it's already hard to find good standards to achieve IND-CCA2 security with (EC-)ElGamal. I'd strongly recommend against using (EC-)ElGamal unless you need the homomorphic property.
Does that mean that there a no know attacks against the raw schemes?
These schemes are different from RSA in that they are fairly "recent" and people already learned how to describe schemes when defining them, whereas the issue with RSA is that it's "just a modular exponentiation with the right exponents", these schemes are comparable in detail of specification to PKCS#1 (i.e. RSA-OAEP and RSA-PSS).
As for the security:
- ECIES is a secure public key encryption scheme (IND-CCA2) assuming the hash can be modeled as a random oracle(RM) and the elliptic curve computational diffie-hellman(ECCDH) problem holds
- ECDSA is a secure signature scheme (existentially unforgeable under chosen message attacks (EUF-CMA)) assuming the EC discrete logarithm problem (ECDLP) holds
- ECDH is a secure key agreement scheme (provided that you authenticate the exchange and that you hash the derived point) assuming ECDDH (EC decisional DH) (or ECCDH + RM-Hash) holds.
- EC-ElGamal is a somewhat secure public key encryption scheme (IND-CPA and maybe IND-CCA1, but not IND-CCA2) assuming that ECDDH holds
See our canonical "IND-" question for the basic notions.