So - whether you display GUI or not is not terribly connected to what user context the installer runs in.
By default, we run things as LOCAL SYSTEM (which has the side-effect that if you were to SHOW GUI-stuff, it wouldn't appear to the user because of how Windows handles sessions now).
You *CAN* run things as "logged on user", (in which case they WOULD see GUI-things) but then have to (likely) contend with the "lack of local admin" permissions.
Option # 3 (in case "LOCAL SYSTEM" isn't good enough) is to run the package as "defined user" ... (domain, local, whatever).
Those are by and large your 3 basic ways to get things going. Whether or not you want GUI stuff displayed is not really directly affecting the user-context it's running in.
In terms of "whitelisting", sure that can be done (depends on your relevant software / component that's complaining) ... if we're talking UAC, then "installing as LOCAL SYSTEM" should not trigger UAC.
Do you have some more context / information here?
The GUI isn't normally an issue, in fact it works for installing drivers and updates. However if a BIOS update is released, the GUI needs to be displayed and it is not.
I am going to try running as local administrator to see if that changes anything right now. You are right, local users don't have admin rights so this won't run in that situation.
So the big question is - "does it JUST need to be displayed", or "does it need to be displayed & clicked on".
If it just needs to be DISPLAYED, then installing it as "some admin user" should work fine (Sure, Windows will display it in a user session that no one will see, but that doesn't matter really). If it needs some kind of clicking ... then you're in a spot of trouble - because your end-users lack the admin rights & the way that Windows handles user sessions makes it impossible for us to run it "as an admin" and yet display the GUI to the end-user.