A. This is because "page faults" are NOT the same as paging to disk. A page fault occurs every time SQL accesses a page in memory that is outside it's "working set". Due to the way that the SQL performance monitor counters work in SQL 6.5 and earlier, this area of memory is held outside of the SQL working set, so access/updates to these counters actually CAUSE page faults.
However most page faults are still to areas that are still held in memory and so do not result in expensive/slow reads/writes to the pagefile on disk. There is some CPU overhead caused by the NT Virtual Memory Manager (VMM) becoming involved and context switches, but these don't affect performance unless you are getting hundreds/thousands of page faults/sec.
The counter you should monitor is pages/sec which is the actual i/o caused to the pagefile, and is what you should be worried about.
For more information on performance/monitoring issues there is no better reference than the NT Server Resource Kit that has a volume dedicated to these topics.