I'd recommend not using LVM inside your VMs. It doesn't buy you much flexibility that you couldn't get at the hypervisor level.
Remember, the hypervisor is already effectively performing these tasks. If you want to be able to arbitrarily resize file systems (a fine idea), just create a separate virtual disk for each filesystem.
One thing you might think of as you go down this road. You don't even necessarily need to put partitions on your virtual disks this way. For example, you can create a virtual disk for
/home; it is
/dev/vdc inside your vm. When creating the filesystem, just do something like
mke2fs -j /dev/vdc instead of specifying a partition.
This is a fine idea, but...most tools (and other admins who come after you) will expect to see partitions on every disk. I'd recommend just putting a single partition on the disk and be done with it. It does mean one more step when resizing the filesystem, though. And don't forget to properly align your partitions - starting the first partition at 1MB is a good rule of thumb.
EDIT - 2013-04-01 - not an april fool's joke :)
I've recently been doing some work with Amazon Elastic Compute Cloud. Virtual disks on AWS's block store are NOT trivially resizable (you can do it, but there's some rigmarole and it isn't fast). So, if you are working on AWS I'd recommend using LVM.
One final thought - Doing this all at the hypervisor level means that you probably have to reboot the VM to resize partitions. Using LVM would allow you to hot-add a virtual disk (presuming your hypervisor/OS combination allows this), and expand the filesystem without a reboot. This is definitely a plus.