I think your requirements seem to be interpreted by somebody quite incompetent.
I would argue that a user is a person and for each of person that will need to have admin access to the database server you need a personal user account, as shared accounts are evil ; you need to be able to hold individual people accountable for their actions.
Services don't belong to a single person but run from service account and service accounts such as the postgres account, are IMHO not the same as user accounts. For starters accounts for people are part of the security process that revokes access for leavers and inactive users...
You don't want to delete the payroll database when Alice from HR who installed it leaves the company, right?
When you don't want to use the stock RPM packages from SuSe for postgres (which will also create the postgres service account) please create your own and provide those to the IT department, rather than doing a manual install.
That way your database administrator user accounts won't need excessive permissions to run an installer, you won't need a big footprint with compilers and build-tools installed on (production) servers, you have a clear list of dependancies and the package can create the necessary service account (or use an existing) and set up all permissions in a way that is much more easy to repeat and audit than running installer scripts.
Create a suitable
sudo profile for the people that will manage the Posgres database server and allow administrators to run the limited subset of commands that a Postgres admin would need to run as the postgres user, i.e.
service postgres [stop|start|restart],
But to answer your actual question:
How avoid the automatic creation of "postgres" linux user by PostgreSQL's installation wizard?
Don't run the wizard, but build from source, use the correct options to select an installation directory accessible to the user running the build and no other user accounts or elevated privileges are needed.
./configure --prefix=/path/to/dir [--other-options]