Unfortunately, not really :-(
I don't have one preferred editor, I am moving between Homesite, Dreamweaver,
Notepad, Word, and a Notepad clone that I have written )and supports whatever
encoding I want).

Homesite 5.5 = sucks for all but Latin 1
Dreamweaver 6 (MX) = dows kind of ok for popular encodings (Latin 1,
Japanese, Chinese, Russian), but bad for others (Hindi, Arabic, for some
reason Korean).
Notepad = ok for UTF-8, since I have a Perl script automatically removing the  
BOM before uploading.
Word = ok for everything. I am using it as a "smarter Notepad", since in the
end I run a macro to convert Word styles to html tags and save as Encoded
text (I don't like the HTML produced by Word)

Now, Homesite 5.5 and Dreamweaver 6 are old, so I cannot tell you how the
newer versions behave.

I cannot talk about the new MS HTML editors (Expression familiy), because I
did not use them (and FrontPage is a long-long time, and hated it time :-)
I am not a WYSIWYG type of guy, and I don't write very fancy struff :-)

Also, I have given up encodings a while ago (using Unicode only :-), so this
saves some of the grief.

In the end, my 2 cents:

First option:
a. Go with whatever editor you like for the features/price, with the
only condition that is should support UTF-8 (VS is also ok for this)
and that you can type using the script you need
b. Write a small script to remove the BOM if the editor wants one, and
also to do code page conversion, if for some reason UTF-8 is not acceptable
(although I don't see any reason to do that)

Second option:
If the preferred editor does not support UTF-8, then try setting the default
system locale to the preferred language, or use AppLocale
(http://www.microsoft.com/globaldev/tools/apploc.mspx)
This is an option only for code pages that can be ANSI code pages
(so, for Russian, Windows 1251 is ok, but KOI8-R or MacCyrillic are not)

The project file can be a great place to store that kind of info.
But, the fact still remains: VS is not a creation HTML tools.
I like it, is very strong, can do a decent job for a lot of file formats,
bat I would not push it too much :-) And in fact, MS does not do it either,
this is whay they have dedicated html tools :-)

When in doubt, I go to the standard :-)
I have no opinion on UTF-8 + BOM in general, but I do have opinions on
UTF-8 + BOM in the context of various file formats.
For some formats is good, for some is not only bad, but non-standard.
One of the good documents is this:
http://unicode.org/unicode/faq/utf_bom.html#BOM
<<Where the precise type of the data stream is known, the BOM should not be
used.>>
In general, Unicode consistently tries to leave decisions to higher-levels
protocols.
There are clear standard methods to identify the encoding of an HTML page,
both as stand-alone file, and as served over HTTP. There is no need for
another one.
And both the HTML and XML (implying XHTML) standards have clear ways to
determine the encoding.
The fact that some browsers handle it properly does not mean is standard.

Fast, from the top of your head, who is the winner here:
- the http header from the server (determined by the server's config) says
    Content-Type: text/html; charset=ISO-8859-1
- the html file has a Content-Type in the head section
    <META http-equiv="Content-Type" content="text/html; charset=EUC-JP">
- the html file has a UTF-8 BOM at the very beginning (EF BB BF)
- the content itself is in fact Shift-JIS

If you got the winner right, then why (according to what standard)? :-)

Agree. Although these days mixing encodings is just a way to ask for trouble,
or show off (look how cool I am, you can master such a mess :-)
There is no reason to be anything other than Unicode. Ten years ago, yes.
Now there are still some exceptions, but fewer and fewer.