After expressing this issue on twitter a bunch of people jumped in with other helpful information:

Dist-ugrade appears to work fine so going from 2018.4 to 2019.1 works ok.
"Installed on Win10 with VMware Workstation Pro 14.1.5 build-10950780 without issue."
"I had the mate version do the same thing on GUI install. Text install worked"
"I tried installing on Workstation Pro 15 and either got unresponsive GUI or unable to detect the ISO to mount during CLI install. That was 64 bit. Haven't tried 32 bit."

I suspect the issue to be the version of VMware used. If you were to try to update your fusion version to 11.0.x (what we use for testing), it should work. Would anyone be able to test this?

Testing on VMware Fusion 10.1.2 with Mojave version 10.14 I experience the same issues. When I use the updated VMware Fusion, 11.0.2, I experience no bugs of that sort. I did not test with the 2018.4 as I already have a VM of that version.

Correction, I messed up and didn't select the right iso on the 11.0.2 test. On an 11.0.2 VMware Fusion version with Mojave 10.14.1 I am unable to use the mouse during graphical install of the 2019.1 64 Bit iso.

I have this same exact problem. This is far as I get.

02.PNG (133,759 bytes)   

02.PNG (133,759 bytes)   

@Gamb1t Can you reproduce the same issue with this Debian ISO ? https://cdimage.debian.org/cdimage/buster_di_alpha5/amd64/iso-cd/debian-buster-DI-alpha5-amd64-netinst.iso

I tried to reproduce the issue on a computer with Windows 10 and VMWare Workstation Pro 12.5.9.

On my first try, I was not able to reproduce the problem with the mouse and the keyboard. Neither with the main Kali 2019.1 image nor with the Debian Buster Alpha 5 image (each time on amd64).

On my second try with the Kali image, the mouse was not working but the keyboard was working.

On my third try with the Kali image, the mouse was again working but the installer failed to identify the network card (I had to go back and let it retry the auto-detection so that it works).

When I compare the "dmesg" output of both cases, I get this interesting output:
$ diff -u kali-{failed,working}-mouse-dmesg-no-timing
--- kali-failed-mouse-dmesg-no-timing 2019-02-26 10:41:53.669165986 +0100
+++ kali-working-mouse-dmesg-no-timing 2019-02-26 10:42:05.077218497 +0100
@@ -1279,6 +1279,8 @@
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
mptbase: ioc0: Initiating bringup

• input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input3
• input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input2
  libata version 3.00 loaded.
  ata_piix 0000:00:07.1: version 2.13
  scsi host0: ata_piix
  @@ -1301,16 +1303,16 @@
  usb 2-1: Product: VMware Virtual USB Mouse
  usb 2-1: Manufacturer: VMware
  hidraw: raw HID events driver (C) Jiri Kosina
• usbcore: registered new interface driver usbhid
• usbhid: USB HID core driver
  scsi 2:0:0:0: Direct-Access VMware, VMware Virtual S 1.0 PQ: 0 ANSI: 2
  scsi target2:0:0: Beginning Domain Validation
• random: fast init done
  scsi target2:0:0: Domain Validation skipping write tests
  scsi target2:0:0: Ending Domain Validation
  scsi target2:0:0: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 127)
• input: VMware VMware Virtual USB Mouse as /devices/pci0000:00/0000:00:11.0/0000:02:00.0/usb2/2-1/2-1:1.0/0003:0E0F:0003.0001/input/input2
• usbcore: registered new interface driver usbhid
• usbhid: USB HID core driver
• input: VMware VMware Virtual USB Mouse as /devices/pci0000:00/0000:00:11.0/0000:02:00.0/usb2/2-1/2-1:1.0/0003:0E0F:0003.0001/input/input4
  on usb-0000:02:00.0-1/input0
• random: fast init done
  41943040 512-byte logical blocks: (21.5 GB/20.0 GiB)
  Write Protect is off
  Mode Sense: 61 00 00 00

It looks like that when it works it detects a PS/2 mouse and a USB mouse, and when it doesn't work in only detects an USB mouse. I'm attaching both dmesg output.

Well this is good news (or bad) I guess, as the original theory was that this was a Vmware Fusion issue. Now the behaviour has been spotted on mac and windows I feel a bit vindicated at least.

Despite multiple tries, I was not able to reproduce the problem (on Win 10 with VMWare WS Pro) with the Debian Buster Alpha 5 ISO image. And yet the amount of difference with the Kali image is not big... they have been created about at the same time. The Debian Buster one uses Linux 4.19.12, the Kali one 4.19.13. They have the same version of udev/systemd I think (240-4).

I then tried with a daily build of Debian Installer: http://cdimage.debian.org/cdimage/daily-builds/daily/20190226-1/amd64/iso-cd/debian-testing-amd64-netinst.iso
This one uses Linux 4.19.16.

I was also not able to reproduce the problem with Windows 10 and VMWare Workstation Pro 12.5.9. I'm keen to know the result for those 2 ISOs on VMWare Fusion. Despite the fact, that I can reproduce the non-working mouse on Windows, there seems to be a big difference in terms how often the problem triggers (i.e. I can work around the issue by rebooting and doing another try) and in terms of impact as well (for me it's only the mouse, the keyboard was working fine).

Coming back to the problematic case where the mouse is not working, since I have the keyboard that works I can switch to a text console (CTRL+ALT+F2) and typed "lsmod" and I saw that the "psmouse" module was not loaded (whereas it was correctly loaded in the working case). So a simple work-around is to run "modprobe psmouse" in that console and I can switch back to the graphical console (CTRL+ALT+F5) and there the mouse works now.

Now we should try to understand why it doesn't get loaded but I think that my first try will be to build a new image with a newer kernel image (4.19.20 that we have available in kali-experimental) and see if it's enough to solve the problem.

I tested out both Debian ISOs and did not experience the problem on either of them even after multiple attempts. I can also confirm that the "modprobe psmouse" re-enables the mouse and it works just fine after that.

So I tried with a new daily ISO (which now uses Linux 4.19.20) and I can no longer reproduce the problem.
http://archive.kali.org/kali-daily-images/

So now the question, do we want to regenerate the 2019.1 ISO images to include Linux 4.19.20 ?

2019.1a is out to address this issue