Short answer. Yes, I think it is fine to choose x as a random 160-bit number. (I would not bet my life on it, but I'm pretty sure it is fine.)
Technical details. There are (at least) two ways to attack Diffie-Hellman.
One way is to use fancy algorithms for computing the discrete logarithm, e.g., based upon the number field sieve or the like. The running time of these algorithms is dependent upon the prime modulus p, and you need p to be large (certainly at least 1024 bits) to resist these attacks.
Another way is to use more basic algorithms, such as the baby-step giant-step algorithm or Pollard's algorithm. The running time of these algorithms is dependent upon the smaller of the size of q or the size of the exponent x. You need q to be large (at least 160 bits) to resist these attacks. You need the exponent to be chosen from a large space (i.e., at least 160 bits of entropy) to resist these attacks.
Since there are two different attacks, you'll need to choose your parameters to defeat both. That's why you need your exponent to be at least 160 bits.
Now the most conservative thing to do is to choose x uniformly at random in the interval [0,q-1] (or [2,q-2] if you prefer, it doesn't really matter). This will surely be secure, as long as p and q are big enough. The quote you pulled out seems to be saying that X9.42 recommends you use this conservative approach.
However in many cases you can get away with an optimization, sometimes known as the short-exponent optimization. The idea is you choose x uniformly at random from some smaller interval, say [0, 2160 - 1]. This is usually secure, if the protocol is designed right, though there have been some exceptions. The benefit is that if q is large, choosing a shorter x like this can significantly improve performance.
For the group you mention, q = (p-1)/2. (*) In other words, q is around 1023 bits long. This means the most conservative thing to do is to choose your x to be from the full range [0,q-1], but I believe you can probably get away with using the short-exponent optimization. I tried to read the IKE documents, and I didn't immediately find an explicit statement of whether the short-exponent optimization is always guaranteed to be safe for IKE, though I did find some passing remarks which seem to indicate that the developers did anticipate it might be OK to use.
Footnote (*): You can infer this as follows. RFC 2409 says that the "properties of these groups are described in [RFC2412]". Section E.2 of RFC 2412 lists the corresponding group, and lists the largest prime factor of the group order. The largest prime factor can be verified to be (p-1)/2. From this, it follows that q = (p-1)/2.
Edit 3/24: I just noticed, thanks to @CodeinChaos's answer, that you mentioned your reason for using a short exponent is not performance but rather the limited entropy in your PRNG. I find this a bit odd. What PRNG are you using? Are you sure you have a crypto-strength PRNG? Most cryptographic PRNGs can be used to pull an arbitrary-length pseudorandom string. If yours doesn't, then you can always take the output of your PRNG and expand it to a 1024-bit pseudorandom string: e.g., generate a 128-bit AES key K, then use AES(K,0), AES(K,1), AES(K,2), AES(K,3), ..., AES(K,7) to generate a 1024-bit pseudorandom string. Once you have a 1024-bit pseudorandom string (as long as it is crypto-quality and the original RNG has enough entropy in it), you can use that as a full-length 1024-bit exponent.
Do check that your RNG/PRNG is crypto-strength. For example, /dev/urandom and CryptGenRandom are good, but rand(), random(), drand48() are all bad. (/dev/random is strong but unnecessary; use /dev/urandom instead, and you will be able to draw a full-length exponent with no problems.) Search on this site for more information about crypto-quality PRNGs.
