If the 32-bit ids are assigned independently, the best you can hope for with a uniform random assignment of ids is a collision probability no more than about $n^2/2^{32}$ where $n$ is the number of ids you have, if $n$ is small; once $n$ grows past $2^{16}$ the probability of a collision rapidly approaches 1. This is the standard birthday paradox.
Using a nonuniform distribution on ids is even worse. The distribution of bits in the encoding of uniform random curve points is detectably nonuniform—enough that it was one of the first problems reported in Dual_EC_DRBG before everyone realized there was a back door. The low-order 32 bits are probably close enough to uniform in this case that it won't affect the collision probabilities; to alleviate that concern you could pass the encoded curve point through a hash like SHAKE128-32 first.
But you should be more concerned with what you hope to achieve using 32-bit ids in the first place! This has been a consistent source of trouble in OpenPGP, for example—fraudulent keys have been forged and uploaded to the key servers for every 32-bit key id possible. To avoid this trouble, you fundamentally need to:
- make the id assignments non-independent, e.g. use a secret permutation of 32-bit strings so that you can have up to four billion ids
- use a much larger id space, e.g. 256 bits
- accept that collisions will happen and find a way to deal with them gracefully, even under adversarial inputs that are all collisions
