At my Day Job(tm) we've encountered a bug wherein if the leading byte of the X or Y value of a public key are zero, "shit happens" (this bug is in our code - I'm not suggesting there's some problem with EC itself. It's just an encoding thing and it's not particularly interesting for this question).
Naively, this suggests that we should expect 1 out of 128 keys to trigger the bug, but that assumes that the X and Y values are evenly distributed. Are they?
If it matters, the curve is secp256r1.
Yes, the coordinates are more or less evenly distributed, between 0 and the order of the curve (exclusive). The Certicom curves such as secp256r1 generally have an order very near the maximum of the bit size, e.g. the secp256r1 curve has the following order $n$:
FFFFFFFF 00000000 FFFFFFFF FFFFFFFF BCE6FAAD A7179E84 F3B9CAC2 FC632551
So that means that there is about one in 256 chances that the first byte is completely zero for each coordinate.
This is slightly different for e.g. Brainpool curves as the order is randomly chosen (for the correct bit size, of course) and thus lower, brainpoolP256r1 has for instance the following prime order $q$ (same thing, different name):
A9FB57DB A1EEA9BC 3E660A90 9D838D71 8C397AA3 B561A6F7 901E0E82 974856A7
So for Brainpool curve the chance that the first byte is all-zero is higher for Brainpool curves (slightly lower than one in 0xA9 of course, so about 1 in 169).
I've seen implementations fix this by making sure that the leftmost byte is set to 00 in case it is missing when constant size X and Y coordinates are required. This strategy fails if the first two bytes are set to zero, with a much smaller but non-negligible chance (somewhere in between 1 in 32768 and 1 in 65536). The chance of three bytes being zero and therefore missing is even lower but still significant, and so forth.
The same thing can happen with EC and RSA private keys (secret $s$ and RSA private exponents $d$ as well as the parameters required for the Chinese Remainder Theorem). The RSA specification lists how to create constant size, unsigned, big endian values that you require in the definition of the I2OSP (Integer to Octet String Primitive) definition. It has mainly be defined for formatting the outcome of RSA calculations (the signature or ciphertext) which also have the same distribution, but it can be used for any similar conversion.
Note that the definition of I2OSP shows a rather mathematical way of saying that you need to prefix enough zero bytes. I've seen a implementations of I2OSP using big integer arithmetic. That is definitely not required; I2OSP just a formal description how it commonly looks in computer memory when you encode the value. For more info, see my answers here on crypto and the implemention on SO for Java.
P.S. The chance of either coordinate starting with a zero byte is about $1 - {({255 \over 256})^2}$. That's ever so slightly lower than $1 \over 128$ as stated in the question, but $1 \over 128$ is a good ballpark figure I guess.
