ahhh, so because the NIC wasn't in use and it was being polled it caused that additional load because the system was trying to poll at something that wasn't there?

No, idlepoll is an optional FreeBSD procedure which polls the network interfaces instead of using interrupts. In some types of loads this polling can give higher throughput than interrupt driven NICs because polling reduces overhead in interrupt servicing.

The vmstat figures for irq19 would be entirely for uhci1+. 16 interrupts a second is probably not a big load but at least three device interrupt service routines (ral0, uhci1 and unspecified, the "+") are called on every irq19 interrupt. That ral0 was unused would mean the idlepoll thread was calling the ral service routine unnecessarily.

idlepoll will effectively result in one CPU being always busy.

irq19: ral0 uhci1+                734832         16

ral0 = your non-active wifi network card.
uhc1+ = some USB sub system.

Strange to see that kind of activity on these two devices, knowing that one, ral0,  isn't used, and the USB business on a firewall is more an exception (maybe a UPS, that's it).

Remove the wifi NIC card to get more details.

edit: ok, saw you post above, seems that polling the unemployed ral0 device was responsible for this.

system –> advanced --> networking

In the second graph where you see the rise of light red is where I reinstalled all my packages. The gap between the rise and the drop is where I reloaded my system from scratch and then uploaded my config back to the system.

I also just now went through and stopped each package one at a time while watching top via putty before restarting the package then stopping another package and repeating with each package until I had gone through them all and it didn't seem like the stopping of any package made a difference in CPU usage.

19 root    171 ki-6    0K    16K CPU1    1 743:13 98.29% idlepoll
  11 root    171 ki31    0K    32K RUN    0 588:56 94.19% {idle: cpu0}
  11 root    171 ki31    0K    32K RUN    1  71:41  6.79% {idle: cpu1}
8516 proxy    44    0    99M 83504K kqread  0  3:17  0.20% {initial thread}
20748 root      49    0  102M 25692K accept  0  0:11  0.20% php

for the top processes and vmstat gives me.....

interrupt                          total       rate
irq1: atkbd0                           5          0
irq14: ata0                           78          0
irq16: bge0 dc0+                     180          0
irq19: ral0 uhci1+                734832         16
irq23: uhci0 ehci0                     2          0
cpu0: timer                     89821972       1999
cpu1: timer                     89821869       1999
Total                          180378938       4015

pfSense shell command vmstat -i will give you interrupt rates,

I suggest you post the output in a reply. In the the pfSense web GUI you can execute a pfSense shell command on page Diagnostics -> Command Prompt.

It could be a problem of a very high squid hard disk cache. On start of squid this can cause a high CPU usage.