I'd conclude it as no. It should not cause data wipe on your bootloader unlocked Pixel device.
Most well known triggers of data wipe are:
bootloader unlock and relock,
manually triggered factory reset,
automatically triggered factory reset
The third one is something harder to talk about. In your case your device is a Pixel device running closest to what vanilla Android has to offer. There is no known (not to me) feature wherein a vanilla Android automatically triggers a factory reset if it detects boot image tampering on a bootloader unlocked device. Furthermore, while I am not certain I don't think Android OS provides a way to device administrator or owner apps to ascertain if the boot image has been tampered with since last boot. As such while a device administrator app can issue a data wipe, it has no reason to. I do suggest that you go into Security settings of your device and see if there is a device administrator app that is enabled as device admin and also has "Data erase / Factory reset" permission. If it does have that you would want to revoke device admin permission from this app before continuing with the process of boot image modification.
As for non-Pixel device owners, all I can say is that you do some related search on your nearest search engine to see if something comes up. A very simple search query such as "flashed modified boot image on my XYZ device Data wiped factory reset" might bring up some useful results if your stock ROM is configured by your vendor to automatically erase user data on detection of boot image modification even on a bootloader unlocked device. Having such configuration enforced for a bootloader unlocked device does not make sense though, and I have not really come across any such case either.
Over and all, you have no reason to worry about at this point. Your device's bootloader is already unlocked so (1) would no longer be triggered. You are not going to trigger (2) because you actively don't want to. And there is no known feature in vanilla Android that would trigger (3), so go ahead, modify or hack the boot image as you see fit.
A strong suggestion: when dealing with hacks and modifications in Android it is best to take a reliable backup of your current state of device and store it in PC. When I say backup I'm not talking about what Android natively offers. That thing is very inconvenient and unreliable. Instead, use a custom recovery such as TWRP which takes backup in a manner you would expect from a backup tool. You give the command to backup and a custom recovery obeys that religiously with superuser privileges. When you ask it to restore a backup it does that too very religiously.
A less powerful alternative to a custom recovery was sugested in the comments. Izzy mentioned that the app SeedVault works better than Android's native backup and restore solution. Here's the relevant excerpt from his comment:
...luckily, Seedvault (the replacement integrated with e.g. LineageOS since Android 10) is way better [than Android's builtin backup and restore solution]. I had to perform a clean flash to upgrade to Android 11, and almost everything came along. Wherever an app had opted out from backup, data was gone – but at least the APK was carried over, regardless of its source: F-Droid, XPosed repo, sideloads – that was a positive surprise.
Go ahead with that solution that suits your requirements of data backup and restore, be it native solution, custom recovery solution, SeedVault, or something else you would come across.
