私自身は、特にＭＳ Ｐ明朝の欧文部分を LaTeX で使いたいという欲求はないのですが、TeX Q and A の過去ログを見ましたら、とても活発なやり取りがあったみたいです：
・11509 LaTeXにおける、和文フォントの半角英数字部分の利用（2002-10-04）
・37494 文字コードをずらす命令（2005-08-17）
・37600 和文TrueTypeフォントの欧文部分における、フォントサイズごとのTFMを作成する必要性について（2005-08-22）
・37767 日本語ttfの半角部分の一利用法（2005-09-03）
以上の議論のまとめが、TeX Wiki にもありました：
・TeX Wiki 全角半角メモ Last-modified: 2006-11-16 (木) 01:18:07
それで、結論（?）としては、サブフォントの最初の 256 個を使う、ということになったようですが、Z. R. さんが作成された Samp0TeXStd.sfd を使えば、OT1 や T1 で使うことも出来るのではないかと思って、試してみました。
もちろん、素直には、
ttf2tfm msmincho.ttc -f 1 mspmin-@Samp0TexStd@
として tfm ファイルを作ることになるのですが、そうではなくて、
ttf2tfm msmincho.ttc -f 1 -T 7t.enc -v mspmin-ot1 r-mspmin-ot1
のようにして、enc ファイルを使って作った tfm ファイルをサブフォントの一員として使うことにしてみました（そうすれば、カーニングやリガチャも有効になると思ったからなのですが、vpl の中味を見てみましたら、カーニングのテーブルはありませんでした…。リガチャについては、enc ファイルに書かれているものが、反映されていました。ただ、7t.enc には fi や fl のリガチャがないみたいだったので、自分で書き足して、別名の enc として試しています）。
それで、dviout の $user.map の設定は、
mspmin-@Samp0TeXStd@ "ＭＳ Ｐ明朝" unicode
として、dvipdfmx の map の設定は、
mspmin-@Samp0TeXStd@ unicode :1:msmincho.ttc
として、試してみた結果の画像と pdf を添付いたします。
Z. R. さんの Samp0TeXStd.sfd は、以下にあります：
簡易包装コーナー → mplus1ps.zip （ダウンロード 59KB） [2011/10/08]
http://zrbabbler.sp.land.to/package.html#sec-simple
応答していただき、ありがとうございます。
> 通常の欧文 ttf でも同じことが引きおこっていますね．
確かに、今、Times New Roman で試してみても、そうなりました（!）。
十日ほど前に mplus-1p-medium.ttf で試したときには、T1 のほぼ全部のグリフを dviout で表示出来たのですが…。
---> http://www.geocities.co.jp/texuttex/dviout_ttf.html
【15分後追記】
…と思ったのですが、ちゃんと確認してみましたら、mplus-1p-medium.ttf でも同じですね。ほぼ全部のグリフが表示出来たのは、sfd を使って作った tfm によるものでした。
Z. R. さんが 「dvipdfmx で OpenType する件について (SFD 編-8)」で、「SFD を .enc の方に合わせる方法」のほうが「.enc を SFD の方に合わせる方法」よりもトラブルが起こりにくい、とおっしゃっていることと関係があるのかも知れません。
dviout で TrueType フォントの T1 をなんとしてでも実現したいというわけでもありませんので、ちょっと状況を整理するだけにして、あまり深追いはしないことにします…。
まず、訂正ですが、
1. タイトルに「dviout で」と付けるべきでした。dviout を使おうとしなければ、わざわざ sfd を使う必要もないですので（グリフ名が異なる場合がある関係で、enc よりも sfd を使ったほうが確実ではあるのかも知れませんけれど）。
2. 「結論（?）としては、サブフォントの最初の 256 個を使う、ということになったようですが」というのも、「unicode のサブフォントの最初の…」と言うべきでした。
3. 「ちゃんと確認してみましたら、mplus-1p-medium.ttf でも同じですね。ほぼ全部のグリフが表示出来たのは、sfd を使って作った tfm によるものでした」というのもまた早とちりで、sfd を使って作った tfm でも、dviout では、0xA7 が section になってしまっていました。
それで、その後少し試してみたのですが、最初は、enc を使って作った tfm を、サブフォントの仕組みに載せようとしたせいで、齟齬が生じるのかと思ってしまったのですが、どうもそういうことでもないようです。
サブフォントの仕組みを使って、TrueType フォントを dviout で T1 で表示しようとすると、0xA7、0xAF、0xB8 が、T1 とは異なるグリフになってしまいます。
0xA7 が section、0xAF が macron、0xB8 が cedilla になるというのは、Windows CP 1252 や TeXBase1Encoding の場合と同じなのですが、どうしてこの 3 スロットがそうなってしまうのかは分かりません。
（あと、もう自分でも再現出来ないのですけれど、なぜか、十日ほど前に mplus-1p-medium.ttf で試したときには、0xA7 だけがおかしかったのですが、今もう一度試してみますと、0xA7 と 0xB8 の 2 つのスロットがおかしくなっています．mplus-1p-medium.ttf の場合には、前も今も 0xAF は racute が表示されています．）
こちらでも追試してみました。しかし、どうやら dviout が正常に動作していないらしく、簡単な回避策もなさそうです。
「Samp0TeXStd.sfd の SFD と ttf2tfm で TFM を作り、そのまま SFD でマップ指定した」状態で T1 のコード表を出力したのが添付画像の上の図です（フォントは Gentium）。ut さんの指摘した文字化けが発生しています。
ここでコード表を上半分と下半分に分けて出していますが、上半分を出力しないようにソースを変えたのが下の図です。TFM も SFD もマップも一切変えていません。かつ下半分の出力の DVI のコードも全く同じはずです。にも関わらず上の図とは「化け方」が異なります（0xA7 だけ化ける）。
（もっと言うと、dviout でこの文書を開いたままにして「上半分を消した」ものを組版して更新させると、この場合は「上の図と同じ化け方」のままになったりします。）
これは TFM の解釈として絶対にありえないので、dviout が異常な動作をしていると推測しています。
