Yes. Any described application that requires a login ships with real account management, not a single shared password: the admin can create further accounts, either able to edit or read-only, each with its own username. Accounts are created from the Settings screen, with a one-time temporary password the person changes on first sign-in.
What "multiple users" concretely means
A generated application that requires a login carries three distinct roles: admin, user and read-only. The admin manages accounts on top of using the application; the user role can create, edit and delete data just like the admin, but cannot manage accounts; the read-only role can view without writing. Each person signs in with their own username — not one password shared across a whole team — so an action stays traceable to the person who took it.
This is not a feature to switch on separately: as soon as your project description implies a login (access restricted to your team, as opposed to a public page), account management is part of what the builder generates.
How an account gets created
From the Settings screen, an admin enters a username, picks the role (editor or read-only), and confirms. The application replies with a one-time temporary password, shown once — never readable again afterwards, by the admin or anyone else. The person uses it to sign in and must replace it with their own on first login.
An account can be disabled — disabling happens in two steps (one click to arm it, a second to confirm), never through a native browser dialog, which would freeze the interface under some automation tools. An admin can disable neither their own account nor the last active admin account: access management would otherwise become impossible to recover.
What the read-only role actually prevents
The restriction is not just visual. A read-only account attempting a create, update or delete — even by bypassing the interface with a direct API request — has that request rejected on the server, before any write happens. It is not a button that is merely hidden: it is a guard enforced on every call, regardless of how it is triggered.
What it does not include
Two limits, stated plainly. First, roles are global to the application: there is no fine-grained, per-entity or per-section permission ("this account sees clients but not billing") — it is edit-or-read-only, across the board. Second, there is no two-factor authentication on a generated application's accounts: the one-time temporary password and the mandatory reset on first login are the protection provided, not a second factor. If your business needs finer permissions or 2FA, since the code is standard, exportable Next.js and Prisma, a developer can add them on top of what already exists.