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.

And it turns out that some UUID implementations are not secure.  For example, [at least some versions of Google's V8 Javascript engine use a non-cryptographic PRNG for random UUID generation](https://littlemaninmyhead.wordpress.com/2015/11/22/cautionary-note-uuids-should-generally-not-be-used-for-authentication-tokens/).  The link describes how to attack such UUIDs—with a couple of lines of code, an attacker who sees one such UUID can reconstruct the PRNG's state when it output that UUID, which allows them to predict all subsequent UUIDs.

So I would not use UUIDs as cryptographic secrets—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.