User authentication, management
Initial thoughts:
This code looks very ... compressed without strictly needing to. Another thing that I notice is the level of nesting that shows in here.
Generally speaking it doesn't particularly make a difference how you decide to handle Promises, in the vast majority of cases it's just a matter of personal preference.
One thing you do not need to worry about is specially handling a promise rejection, since express automatically converts thrown errors into an appropriate response. That is what login takes advantage of to look so clean.
One final initial thing I notice is the inconsistency that shows in the code.
Inconsistencies:
Compare the use of spaces in the following example:
const  user   = await User.existLogin(req.body.login);
const isPassword = await User.isPassword(user.dataValues.password, req.body.password);

Or compare the use of braces as well as whitespace for these examples:
if(!token) return res.status(401).json('Unauthorized');
if (!user) { return res.status(400).json({result: 'Login is wrong '});}
if(!user){
    return res.status(404).json('User not Found');
}

Compare also the use of newlines and indentation levels in the following examples:
User.create({
    name, email, login, password }).then(result =&gt; {
    res.status(201).json({Results: result.dataValues})
})
return jwt.sign(payload,
    config.secretToken
           )
return {
    sub: usuario.id,
    // ....
    exp: moment().add(10, 'minutes').unix()
}

All this is to say: Pick one style and stick to it. Whichever style you decide on, it makes it easier to read if the style is consistent.
Personally I prefer a style with more space than you've shown here for most cases.
Indentation:
You're using a strange mix of indentation styles and you're making lots of use of early returns, except in some small cases where I don't understand it. I personally prefer to almost always return early inside the request handler and if there's more complex logic I'd consider extracting that into a separate function. That yields code which will look a lot like this:
function addUsers(req, res) {
    const name = req.body.name;
    const email = req.body.email;
    const login = req.body.login;

    const exists = await User.existLogin(login);
    if (exists) {
        return res.status(409).json({ message: 'Login already exists' });
    }

    const password = bcrypt.hashSync(req.body.password, 10);
    const created = User.create({ name, email, login, password });
    res.status(201).json({ results: created.dataValue });
}

Note that I removed the use of await with hashSync (should be clear why).
Also note that I lower-cased the member results in the returned JSON result.
Obviously this doesn't quite have the same error behaviour as the code presented in the question, but it nicely shows how to avoid deeply nesting blocks.
HTTP / web standard authorization patterns
As a minor point I'd like to add that the auth middleware shown here is not quite following the common header authorization pattern. It's missing a response header indicating the expected authorization type. Since you're working with a token here, usually the header would be 'WWW-Authenticate: &quot;Bearer&quot;', but that would imply the expected Authorization header should start with &quot;Bearer&quot;, which is not the case here.
To be more ... standard-conform I'd expect a proper bearer-token Authentication scheme to specifically define the authorization type used in the scheme. An option could be to explicitly specify you expect a jwt-token as type resulting in the following headers:
'WWW-Authenticate: &quot;jwt-token&quot;'
---
'Authorization: &quot;jwt-token &lt;jwt_token_goes_here&gt;&quot;'

Note that this suggestion of course would require an adjustment to the way the token is obtained, adding another way the request can be malformed :)
Conclusion:
All in all this is a solid start, to get this code to the next level just requires a few tweaks, mostly around being consistent in how the code is structured in itself.
Well done :)