Thanks to all that have replied. I've learned a lot of interesting things since I first posted. In fact, I have DNN happily running at last. Here's what I've found:
On my two servers, the NT AUTHROITY\NETWORK SERVICE account is completely inaccessible through the UI. I know this sounds unlikely; I whish I could demonstrate this through direct access to all doubters, but I have done so for several, so I feel confident that it's not user error (which I am not immune to.)
The NT AUTHROITY\NETWORK SERVICE account does actually exist. The default Application Pool runs under this identity, and I find it peppered throughout my system. My salvation came through a friend trying the 'cacls' command line tool, which attributed the DNN directory for the missing account without any problem. The account is there, it is just consistently and universally denied by the UI, on two different (but similarly configured) machines.
Both machines are domain controllers which are running Exchange, DNS, ASP.Net 2.0, Perl, and perhaps a few other things. One is Windows Server 2003 with Exchange 2003, the other is Windows 2000 with Exchange 2000.
I've examined a few other machines, and have found that this problem does not exist on:
Windows 2003 Server configured as an Active Directory Domain Controller.
Windows 2003 Server configured as an Exchange 2003 server (not a domain controller)
Windows 2003 Server configured as an ASP.Net 2.0 application server (not a domain controller)
No additional testing with DNS, but this seems an unlikely candidate.
I intend to do further testing and determine exactly which combination of installations obfuscates this account. Searching the web, I find several similar reports. I imagine the root cause is very similar.
If this happens to you, use cacls to set up DNN like this:
cacls Website /e /p "NT AUTHORITY\NETWORK SERVICE":R
cacls Website /e /p "NT AUTHORITY\NETWORK SERVICE":W
cacls Website /e /p "NT AUTHORITY\NETWORK SERVICE":C
Using iisreset may be in order, too, after making changes.