You may probably use any curve you like, depending on your special requirements (environment, computational aspects, ...) and the curves implemented by your library (see otus answer refering to some concrete security findings related to specific elliptic curves, and how sensible they are to certain attacks). The reason why the curves are pre-computed, is because it is much harder to set up an EC crypto system than one based on a "standard" cyclic group with integer elements rather than points on a curve (the actual reason is that it's time-consuming to compute the order of a curve).
Even though the outer parameters of the curve are public domain ($a, b, p, order(E), P$) there are not enough ink-atoms in the universe to store all points of a curve (given the number of points on the curve is large enough - see "security levels" below). This means, that you don't need to be worried, that one curve may be less secure than another because someone might have precomputed and stored all the points, which would render security nil.
For the key-length the parameter "size" published on the bouncycastle page probably refers to the minimum size in bits of the hash output, which is a the same time the order of the cyclic group generated by the chosen generator point $P$. You can call this your key size.
Today (in 2014) in ECDSA the security level of a 192 bit key is 96 bits, and a 512 bit key provides a security level of 256 bit.
A security level of $n$ bit means that the best known attack for that algorithm at that point in time requires $2^n$ steps. Since research is ongoing the selection of a security level is a trade off between efficiency and the belief that the best known attack is not the actual best attack (to come). In any case it is a function of time.