There isn’t a way to stop FusionAuth from synchronizing the user object when using a generic connector. Even when a third-party system is the “system of record,” FusionAuth still requires a local user record to support its internal workflows and features. If you choose not to migrate users into FusionAuth, your external system must also provide application registrations on the returned user object to ensure proper integration.

Regarding your first question, there’s no way to prevent an error if the user.id changes between logins. The id field in the user object should remain consistent across logins. Changing it will inherently cause issues with how FusionAuth matches and manages user records.

For more detail, see the documentation here:
Using the Generic Connector as the System of Record

At this time, the generic connector in FusionAuth only supports a single error response type:

The connector returns a 404 Not Found in any failure scenario, whether: The user does not exist in the external system, or The user exists but provides invalid credentials.

This design is intentional and exists to prevent user enumeration attacks by not revealing which part of the login process failed.

Because of this security restriction:

You cannot display different error messages on the hosted login page for different connector failure scenarios. There’s no way to pass additional custom data or error context from the generic connector to the hosted templates for display purposes.

You can read more details here:
Generic Connector - Response

Existing Role Limitations in FusionAuth FusionAuth provides predefined Admin UI roles, which are not modifiable. You can review the available roles here:
FusionAuth Admin UI Roles The default FusionAuth application roles cannot be changed, which means read-only roles are not currently available. Requesting Read-Only Roles as a Feature FusionAuth does not currently support read-only access roles for applications or tenants. The likely reason for this is that users who need to view application/tenant properties often also need to update them. However, you can submit a feature request to suggest adding read-only roles:
Submit a Feature Request Workaround: Implement a Custom Read-Only View

If immediate read-only access is required, consider:

Using the FusionAuth APIs to create a custom dashboard where users can view but not edit data. Relevant APIs for this purpose: Application API Tenant API

Summary

No built-in read-only roles exist for applications or tenants. FusionAuth Admin UI roles are not modifiable. You can request read-only roles as a feature via GitHub. A workaround is to build a custom, API-based read-only view.

Existing Role Limitations in FusionAuth FusionAuth provides predefined Admin UI roles, which are not modifiable. You can review the available roles here:
FusionAuth Admin UI Roles The default FusionAuth application roles cannot be changed, which means read-only roles are not currently available. Requesting Read-Only Roles as a Feature FusionAuth does not currently support read-only access roles for applications or tenants. The likely reason for this is that users who need to view application/tenant properties often also need to update them. However, you can submit a feature request to suggest adding read-only roles:
Submit a Feature Request Workaround: Implement a Custom Read-Only View

If immediate read-only access is required, consider:

Using the FusionAuth APIs to create a custom dashboard where users can view but not edit data. Relevant APIs for this purpose: Application API Tenant API

Summary

No built-in read-only roles exist for applications or tenants. FusionAuth Admin UI roles are not modifiable. You can request read-only roles as a feature via GitHub. A workaround is to build a custom, API-based read-only view.

No, the users must have a password. In this scenario, where you know the users do not have a password, you can just set a secure random password. A UUID, or other securely generated high entropy value.

You can provide the password value, but this will cause FusionAuth to hash it inline, so it will be costly in terms of time and CPU if you are importing a large number of users.

If you don’t want to take this hit at import time, you can provide these users just random hashed values, as long as you provide the factor, encryptionScheme, salt and password FusionAuth will assume this is a hash, and it will not re-hash it.