It sounds like the permissions changed, which affects that Admin account you are using.
I used to support about 2 dozen VMs at my last shop, and the way we got around not being able to save the Hosts file was to make a copy of it in a different folder, make the changes there, than copy and overwrite the original. Modifying a file in the folder requires elevated permissions, whereas simply copying and overwriting does not.
To help facilitate this, I created a batch file that would copy the file to the current users desktop if it didn't already exist there, and if it did exist, then it would move it back. That way I could double-click, make the changes, save it, then double click again and I was done.
It's not elegant, but it's fast and easy.
is an administrator account as safe these days as a standard account
coupled with the built-in Administrator account when needed?
In short: Still no.
The longer answer...
UAC is not a security feature
Back in the days of Windows XP and previous versions of Windows, it was quite difficult to practice the Principle of Least Privilege, not least in a corporate environment. The principle implied that you would do all your day-to-day tasks using a standard user account. Any tasks requiring admin privileges would be executed using a separate account with admin rights (given that the user had a legitimate need for it).
But Windows XP wasn't designed with this in mind, and there were many quirks and limitations, when running as a standard user - even if you also had access to an admin account. As a standard user, you were not able to click on the systray clock to show the neat month calendar, you couldn't change network settings and the "run as" function didn't work for everything (especially Windows Explorer, and thus also Scheduled Tasks, Printers and other shell folders, if memory serves me right).
Of course there were workarounds for a lot of these deficiencies, but it took a lot of time to discover, document and, well, work around them.
Security is a balance between, well, security and convenience. UAC was introduced with Windows Vista, primarily to detect when admin rights were needed, and to automatically prompt you to authenticate with an(other) account, with admin rights. This made practicing the Principle of Least Privilege a lot easier.
As a side-effect, performing tasks requiring admin rights, while logged in with an admin account, gives you a chance to actually confirm that you want to exercise these rights. UAC prompts when installing software seem reasonable, whereas when opening a normal webpage doesn't.
However, it turns out most users don't use separate accounts and quite a few day-to-day tasks require admin rights (adjusting settings for clock, network, power plan etc.), and would thus trigger an UAC prompt in Vista. This slew of prompts causes most users to
a) Blindly accept any UAC prompts, with no attention to what was actually requiring elevation, or
b) Disable UAC confirmation entirely
With Windows 7, Microsoft made several Windows executables auto-elevate permissions, so if you you're using an admin account, some actions are automatically executed with elevated (admin) rights. This made UAC seem a lot less obtrusive.
UAC auto-elevation can be exploited
So, in Windows 7 there's a built-in mechanism for auto-elevating rights. If this mechanism can be exploited, by an application running with standard user rights, then UAC (which was not designed to be a security mechanism), can be circumvented and you can end up running applications with admin rights, though you haven't been prompted to confirm it.
Turns out UAC auto-elevation can in fact be exploited by injecting code, as proven by Leo Davidson (Windows 7 UAC whitelist: Code-injection Issue (and more)) and discussed and demonstrated by Long Zheng (UAC in Windows 7 still broken, Microsoft won’t/can’t fix code-injection vulnerability).
Conclusion
Seen from a security perspective, it still makes sense to use separate accounts for day-to-day work and anything requiring admin rights. This is the only way to be (reasonably) sure, that no applications run with admin rights, without your explicit authorization.
That said, it's a balance between convenience and security. As pointed out by @GeminiDomino, you could also fill all ports with epoxy, as used by the military. You could also run your computer "air gapped", like Bruce Schneier, so that it never directly connects to any network.
In the end it comes down to if you're OK with having to explicitly authenticate when performing admin tasks or not.
Best Answer
Since the problem is that you have added registry entries to hide the Administrator account, you have basically managed to make unavailable your only enabled administrator account. For reasons you have already found out, Windows takes special care to ensure that there is always at least one such functioning account, but you have found one way of circumventing all these safeguards.
So basically the problem is narrowed down to how to delete these registry entries without using regedit. They are found in the registry at the key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList. Deleting the wholeSpecialAccountsbranch is probably the best.There are numerous ways of modifying the registry in an unrestricted manner and without booting into Windows and numerous articles describing them. For example, this article details four such methods : 4 Ways to Edit Registry Key Values Without Booting into Windows.
A fifth method, if you have a Windows installation disk or a System Repair Disc, is to boot from it into the Command Prompt and use regedit. See the article How to Reset a Windows Password in Regedit at Boot.
However, all of the above methods involve using a boot CD/USB. If, as you say, you currently don't have access to that, you are in a bad way. Please explain why you have that restriction.
Without being able to boot a CD or USB, the only other solution I can think of is to take the Windows system disk out of the computer, add it as a secondary disk in a functioning Windows 7 computer, and use its regedit to open the HKEY_LOCAL_MACHINE hive and delete the SpecialAccounts branch, as described in Load or Unload Registry Hives.
The HKEY_LOCAL_MACHINE\SOFTWARE hive is located in the file
\Windows\System32\config\SOFTWARE. You need to open regedit, click on HKEY_LOCAL_MACHINE, then use the menu File -> Load Hive command. After editing, use File -> Unload Hive.