UUIDs do not generally guarantee unpredictability or any security properties.  As [RFC 4122](https://tools.ietf.org/html/rfc4122) says (section 6):

> Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example.  A predictable random number source will exacerbate the situation.

What you require here is a *cryptographically secure random number generator*.  Some UUID implementations are driven off such RNGs, but that's an implementation choice, not a guarantee.  The [ITU standard](http://www.itu.int/rec/T-REC-X.667-201210-I/en) explicitly says that the use of cryptographic random number is **recommended**, which clearly implies it's not a requirement (p. 10):

> The use of cryptographic-quality random numbers is strongly recommended in order to reduce the probability of repeated values.

So I would not use UUIDs as cryptographic secrets for that reason—I'd interface directly with the cryptographic RNG, at least to make the *intent* of the code evident.

The bigger problem is that your users wouldn't be able to remember such tokens; they'd have to store them somewhere secure, and you'd be providing no assistance for so doing.  The unobvious but actually very natural alternative here is to use a multi-factor authentication system based on passwords *and* secret keys, like [TOTP](https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm).  For example, if you build an integration with [Google Authenticator](https://en.wikipedia.org/wiki/Google_Authenticator) or [Authy](https://www.authy.com/), your users get the benefit of those vendors' user-side apps to store and manage the shared secret key.