By importing the Boot Camp partition you have actually done nothing to change the situation of running low on disk space and will need to take additional steps to do so but first lets address the bastardized* way VMware imports the Boot Camp partition to a normal file based Virtual Machine. Have a look at my reply to Re: Counterintuitive Instructions from VMWare on Resizing Virtual Disk to get some perspective on this issue.
*The reason I'm calling VMware's import of the Boot Camp partition "bastardized" is first and foremost it doesn't create a normal partition layout as when a Guest OS is installed in a normal newly created file based Virtual Machine and secondly can leave the User in the same place, not enough disk space, without having to take additional steps. In other words IMO the Import Function should create a normally partitioned disk with the OS at the head of the disk and give the User the opportunity to set the size of the virtual hard disk, not leave a layout as shown in the images in the linked reply! 
Anything short of this is unacceptable!
Now while in the linked reply I showed moving the NTFS Partition to the head of the disk I do not necessarily recommend doing this and would instead use an alternate method to create a new normal file based Virtual Machine using a Image made of the OS installed on the Boot Camp partition using a right-sized virtual hard disk to begin with while writing the Image to it. IMO This is the fastest and easiest way to have a Virtual Machine that is in essence no different then if clean-built as a normal file based Virtual Machine to begin with and not a bastardized import of the Boot Camp partition.
As an example if you had already run the Physical Boot Camp partition as a Virtual Machine then all the necessary Drivers and Windows Registry Entries are present and you should be able to Image the Boot Camp partition and dump the Image to a new right-sized virtual hard disk and then when boot it you should not get a BSOD due to hardware differential however you do need to account for the partition number it was originally installed on. If the Boot Camp partition is running Windows XP this is as easy as editing the boot.ini file however if Windows 7 you'll need to use the Windows 7 DVD and repair the bootloader.
If you haven't run the Physical Boot Camp partition as a Virtual Machine the the necessary Drivers and Windows Registry Entries are not present and just creating an Image to drop on a new right-sized virtual hard disk will result in a BSOD even if fixing the bootloader. This would then require one to manually inject the necessary Drivers and Windows Registry Entries.
Another alternative may be using VMware vCenter Converter when running the Boot Camp partition OS natively and create a Virtual Machine that way however I have not tried it in this use case scenario so I do not know what the end results will be. I have just always used Symantec Norton Ghost to create images in a P2V scenario and then injected the necessary Drivers and Windows Registry Entries as needed either manually or via scripts I've created.
Another option might be to use a product like Winclone 3 to create an image and then restore this image to a virtual disk instead of the physical disk. Although this method would require the ability to mount a virtual hard disk under OS X and VMware Fusion 5 does have the VMDKMounter.app like previous version have and would require extracting from a previous version, like 3.x and manually installing it.
In VMware's defense I do understand why they import the Boot Camp partition the way they do, it's the easiest and safest way it can be done and it does technically create a file based version Virtual Machine of the physical Boot Camp partition. However I just have never found how they do it acceptable.