What makes it difficult to have a hardware antivirus?
If the chip is writable from within the OS, the malware can write to it too, so it wouldn't help there.
Also, anti-malware software has to handle threats that are only a few hours old. Having to reboot your computer to upgrade the anti-malware software that's running on its own hardware would suck, so we need to be able to upgrade it from within the OS. If we can write to the chip from the OS, so can the malware.
In order to make a secure hardware anti-malware you first have to change the main task of the program. Anti-malware software basically have a list of malicious software. If a program is in that list, it's blocked and removed. If not, we let it run. Every time a new piece of malware is written we have to add it to the list. Thus, the software can only be reactive, with the need to update the (huge) list all the time. If, on the other hand you have a list of programs that are allowed to run and block everything else you don't need to update that list all the time; only when you want to run a new program. Any malware, unknown or well known, would be blocked by this implicit deny. For many sensitive environments you don't install new code every day. ATM's need to run one piece of software. Nothing else. The list basically wouldn't change.
The problem is that there is no generally feasible list of OK programs. You'd either have to have a relatively small list of the programs you need to be able to run on your computer, which has to be made specifically for you, or you'd have to have an enormous list of any programs that anyone would ever want to run.
To generate that list, the easiest would be to add every possible program, and remove all the bad ones, which is equivalent to what anti-malware software does today, rather that the implicit deny. You simply cannot get a list of all non-malicious programs that will ever be written without including ones that won't be.
It could work, if you do it right. But it's generally not feasible. Also, it would really be a terrible thing to change to implicit deny for anti-malware companies trying to sell subscription services.
As for the extra privilege level; sometimes you have to escalate privilege, and if you can, malware will. And the inability to edit system files, you just added another layer. The top layer will still have that problem.
There is no difficulty in BIOS based malware/viruses, they already exist, as does "memory only" malware. Had I to guess why it isn't more prevalent than normal viruses/malware, I would say that this is because BIOS software is vastly different than a normal operating system. There is a cost associated with creating malicious software, and the authors are likely targeting software where they can get the most bang for their buck.
Let's pretend to be software developers for a moment. We design our software to be compatible with as many devices across the board. Here are our choices with a generic value for the amounts of users we'd like to see run our software:
Windows Users - 10
OSX Users - 4
Linux Users - 4
Others - 1
Where does BIOS fit into the equation here? Let's take a few samples of BIOS manufacturers
Phoenix
Asus
ACER
AOPEN
Dell
Fujitsu
Gateway
IBM
Intel
And that list grows and grows. As a software developer, why would I want to focus on creating something that targeted when I'd have no initial idea of what BIOS software my client would be running. It is not cost effective. Now, let's replace the above instance with a "malicious software developer." What incentive would they have to focus on say 30+ BIOS manufacturers, versus say: 2 operating systems which are heavily used.
There has never been a time where it has been difficult to create BIOS based "on chip" like viruses. It is not cost effective. Most malicious software developers create their executables to scale, it just makes sense. Normally, when I have analyzed BIOS/boot based things, it has appeared to have been a highly targeted attack. Developing these types of exploits take time, a lot of recon to ensure you're sending the right exploit to the right target (you wouldn't waste time creating ASUS based malware, only to discover your target is using Intel based BIOS firmware.)
Malicious authors on say the state level vary differently from cybercrime groups. Some of these guys (state actors) disappear in certain countries. Why chance spending so much time, effort, and money to target the BIOS software when you could focus on the operating system, then move to memory.
Modern OSes already have privilege isolation, and modern antivirus programs already use that mechanism to try to avoid interference from lesser privileged malware.
There's no reason in principle that you can't introduce yet some higher privilege level (which seems to be the thrust of your question)--many people use virtual machines to do exactly this. (There's no reason for this to be "hardware antivirus," however.)
Any interface between the lower privilege and higher privilege execution contexts is, of course, a possibility for privilege elevation vulnerabilities, which occur both in the OS itself and, with somewhat greater rarity, across virtualization boundaries (e.g. http://threatpost.com/virtual-machine-escape-exploit-targets-xen-090612/76979, http://www.kb.cert.org/vuls/id/MAPG-8TVPQL), so this isn't a panacea.
But in reality, the problems with antivirus are deeper and more fundamental than the issue of privilege isolation. Antivirus engines are of questionable value (given the heuristic nature of their detection) and are often themselves a source of vulnerabilities--building a big bag of file parsers that try to parse every file on disk (often with elevated privileges!) is just a recipe for disaster (e.g. http://www.blackhat.com/presentations/bh-europe-08/Feng-Xue/Whitepaper/bh-eu-08-xue-WP.pdf, http://mincore.c9x.org/breaking_av_software.pdf).