As a fellow EqualLogic user, I feel that I can answer these pretty well for you. First, I'd really suggest my 5 part post on Replication with an EqualLogic SAN (http://itforme.wordpress.com/2010/04/30/replication-with-an-equallogic-san-part-1/). I go over every aspect of how to make it all work in the real world. Print it out, and read it a few times over. It has been very well received in offering practical recommendations in how to make it work.
Seperating out OS paging files can be done depending on the OS, but it can lead to a very complex arrangement in that you have to anticipate how the replica is going to react when it doesn't have the page file, etc. What I recommend is addressing that at a later time (if at all. Yes, it can get messy). It sounds like you have bigger fish to fry at the moment. However, the other swap file that you can easily elliminate from replication is the hypervisor based paging file for each VM. This one is an easy one to do. Just have a dedicated datastore/volume for all of your VM swap files (again, these are the VM swap file, not the page file inside the OS), and dont' worry about replicating that volume.
For systems that are serving up SQL, Exchange, or large flat-file data storage, you have a good opportunity to take advantage of one of EqualLogic's features; guest attached volumes. Lets say for a SQL server, you'd have a VM that had a relatively small vmdk that is the C:\ drive. Then, create two more volumes on the SAN. Install/configure the EqualLogic Host Integration Toolkit/Microsoft Edition (HIT/ME), and connect to those volumes. When you install SQL, have your SQL databases go on one attached volume, and the transaction logs go on another. The great part about this is that you can snap or replicate you data volumes using the AutoSnapshot Manager/Microsoft Edition (ASM/ME) at the frequency you desire, and it makes FULLY application aware snapshots and replicas. (criticial for SQL, Exchange, and some flatfile storage). If you choose to not have them as guest attached volumes, and just additional VMDKs, depending on the cirumstances they are just hypervisor aware snaps, and do not take full advantage of VSS.
So in short, you could have a VMFS datastore of say, 600GB, put a bunch of VM's in there. The VM's that are in there that require this special storage, just use guest attached volumes. That way you keep your OS footprint small, and improve your snapshot and replication efficiency.