I have look in the CLM Platform manager to disable that functionality as it's OOTB with CLM, but unforunately I couldn't find where that functionality is configured. I don't mind disabling it, eventhough it's a functionality used with Windows and other OS.

I had to do something similar to this in my CLM environment. What you should do is create a separate NSH script that will delete this user when it is executed. Then turn that into a ACT deployment. Add that ACT as a functional component in your CLM blue print. That will make sure it executes every time and avoids any race conditions. In our case, we have a batch job of required post-provisioning tasks that run after the OS is provisioned and before any of the customer's optional software is installed (patching, compliance scans, config changes, etc) so we just added our script to that batch job, which was already a functional component in our blue print. This is essentially how you do post-provisioning batch jobs in CLM.

We did exactly what Adam suggested above as well. Forget about trying to get rid of the native local user creation as also previously mentioned in this thread.

We didnt do an ACT though, we did an NSH Job and ran it as a BAO Callout attached to VirtualGuest_CONSTRUCTOR PostCallout and assigned weights to order it in context to other Callouts attached to that provider.

ACTs are executed way too late in the provisioning process (its way past VirtualGuest_CONSTRUCTOR PostCallout) and there is no ordering if you have more than 1 ACT to run against that SOI request. But if you are not concerned about sequencing (e.g. you need a user created in your VGP before running another ACT), then Adams suggestion is the easiest way to go.