Stream cipher vs OTP, with /dev/urandom and secure key exchange My application will work in an office setting where a user can directly and securely collect a long One Time Pad.  For example, it may be 16Gb on a USB drive.  This would fill me with joy except that the OTP will be generated from /dev/urandom and therefore is not 'truly random'.
I understand that /dev/urandom is acceptable for most cryptographic uses, but my OTP would no longer be information-theoretically secure.
In this circumstance, should I continue down the OTP path, or use a stream cipher instead?  Are there other factors to consider?  (Note: I believe the staff can store their OTP securely).
Are there other factors to consider? (Note: I believe the staff can store their OTP securely).

The obvious issues are authentication of data and storage of keys.  I will presume the data being encrypted is personal to each staff member, and is not to be transmitted between staff.
You note that staff can store their OTP securely, on USB drives.  What happens if they get lost?  If the storage used for keys cannot be lost and is secure, you could just store the data there.
I think you have to question how secure a physical piece of storage can actually be.  It's certainly never close to being secure against unlimited physical power in a manner analogous to information-theoretic security.
Data authentication would need to be carefully implemented in order to not affect the security of the scheme, and would require using pad data.  Per Wikipedia:

Universal hashing provides a way to authenticate messages up to an arbitrary security bound (i.e., for any $p &gt; 0$, a large enough hash ensures that even a computationally unbounded attacker's likelihood of successful forgery is less than $p$)

Per the helpful user Poncho:

you can do data authentication with an OTP (and preserve the informational security properties); for example, using an epsilon almost-universal hash function (with OTP providing both the UH keys and xoring the hash output)

Not using data authentication would mean that the data could be tampered with so it seems unlikely that this would be the case.