I wonder, even if you damaged the port, if you could now connect a self-powered hub to it and try that since you may still have the communication aspect of the on-board USB working.
Seems odd the MBD would show up as a COM port, or interract with it in anyway. It should have it's own driver and having just connected one that I have, should show a VID (vender ID) of 0x1058 in the device manager. I think the original USB spec allowed 150mA for that type of device (only 100mA for things like the arduino - I think) but that was later bumped to 500mA, and finally 900mA, with all the changes just due to how the driver handles power management. If you want to pursue possible issues with the drive, perhaps take an old USB cable, strip the insulation to get to the power wire, and check the actual current draw of the drive. If it's excessive then that's a problem and should be reported to WD, or at least allow you to get a replacement drive from where you got it?
Maybe also see if that chinese clone is installing it's own driver (.sys) or using the onboard usbser.sys. If using it's own driver, check it's VID and see if it's "stolen use of" someone else's issued VID or if it's actually it's own. The arduino, for example, makes use of the windows on-board usbser driver while things that use an FTDI chip use the one provided by FTDI which has it's own driver. Finally, the chinese driver installation file, if installing it's own .sys, but is installing itself with a class definition for the usbser, that could create some kind of conflict. That can be found in it's associated .inf file if it installed it's own .sys and should be USB rather than USBSER, but I'm not sure if that applies in every case - something you could research.