PKCS#12 uses a generic and standard format for privatekey entries (PKCS#8) which supports ECC as well as RSA and other algorithms, so for software that supports ECC in the first place, the equivalent of PKCS#12 is PKCS#12. PKCS#12 is a good solution for password-protected transfer as well as storage. Formally PKCS#12 can be used with no password, but neither Java JCE nor any other software I know of supports it. However nothing prevents you from using a weak password; if you want actual security, choose the password(s) well.
JKS also uses a generic format for privatekey, but (IME) the password "protection" can be provider dependent. If your JVM/JRE uses any ECC provider you can create a privatekey (with at least dummy cert, and preferably real cert chain) in JKS, or import a privatekey (with cert chain) from PKCS#12 to JKS, with standard keytool. However, if your application uses a different ECC provider, namely flexiprovider, it may fail to use that key. If so or to be safe, create or import with keytool specifying the particular provider here flexiprovider.
Note you can never have a privatekey alone in a JKS, it must have some kind of cert chain, even it's a dummy selfsigned cert that nobody trusts. Of course for an asymmetric key to be actually useful for securing data it needs adequate integrity assurance, like a PKI certificate or PGP-style web-of-trust. FWIW, JKS also uses a generic format for certificates, namely X.509.
AFAIK BKS is custom to bouncycastle and only supported by the bouncycastle provider. I expect you probably can't use BKS with flexiprovider for any privatekey (and maybe not even cert), although it wouldn't hurt to test. However the bouncycastle provider is documented to support ECIES, so you should be able to use BC for ECIES with the privatekey in BKS.