Question: If I want to persist the users' login such that they do not have to re-login even after, say 1 year of inactivity, then is storing a permanent access token as good as storing the password directly (perhaps hashed), since the (permanent) access token would essentially be the "alternative password"?

Answer: 
Storing an access token is surely safer than storing the password directly, but let's see why:

1. An attacker can only get this token, but not the original password. This is better, because passwords are often reused on other sites, and/or can reveal password schemes. ➽ Make sure the token is random and not derrived from the password.
2. The token is not just another password. While passwords choosen by a user are often weak, a token is very strong. They are so strong, that brute-forcing is impractical. ➽ Generate random, long enough tokens, they should be at least 20 characters a-z,A-Z,0-9.
Generally speaking, yes. **But**, with a lot of caveats.

A long, random token, *generated by a CSPRNG* (this is very important, there are different ways to generate "random" strings and not all of them are really random), is stronger than a password - yes. However, the way you intend to use this token means that it is effectively a password by itself, and that means the same criteria applies:

* It can't be permanent.

A key property of passwords is that they are not constants and users can change their passwords when stolen, or otherwise over time. Any kind of token should be no different, except that it should be automatically changed (rotated) by your application, on regular intervals.
* It MUST be hashed!

(with a strong algorithm: bcrypt, scrypt, Argon-2I, PBKDF2; anything else is plain wrong)

Don't ever store user passwords in plain-text format, anywhere. Even if it is guaranteed that the user doesn't use this password on any other site, a plain-text password means that anybody who gets their hands on the database (even for a brief time), can hijack user accounts.  

You have a responsibility to protect your users not only from "hackers", but from yourself as well.
* Don't store it in a cookie, even if hashed or encrypted.

The way you've worded the question implies that you would do something like this. Cookies are not a secure location to store passwords of any kind. *Temporary, short-lived tokens* - sure, but not passwords.

It looks like you're trying to design your own authentication protocol, which is not an easy thing to do. It may be easy to make it work, but that's about 5% of the job; there's just too many details to consider. And all of this, for the tiny benefit of saving the minor inconvenience of a user typing-in their password once in a while - people are used to this; it's not worth the security risks.

In case you are hell-bent on providing long-lived logins, I would recommend using an existing authentication protocol. Every such protocol uses on cryptographic signatures, avoiding reliance on user passwords altogether and thus eliminating all of the above problems almost entirely.

Personally, I would just allow the so-called "social logins" - via Facebook, Google, Twitter. You wouldn't have to handle passwords at all, and anybody can login with a single click of a button.