Anthony,

The internal fragmentation has nothing to do with the file level
fragmentation.  They are really two separate things and dealt with in
different ways.  The disk defrag tool sees where there are gaps in the file
but knows nothing of the way the tables and indexes are positioned within.
It is always a good idea to start with a contiguous file on disk and if it
is fragmented at the OS level you can use something like Speed Disk to
remedy this.  Just make sure you have a good backup first and it is a good
idea to stop sql server before you attempt it.  The fragmentation within the
file is handled totally by SQL Server.  Although there can be a performance
difference if you are reading a file that is physically located near the
outer edge of the platter vs. the inner edge it is usually more important to
ensure the table / index is contiguous first.  As such it doesn't matter a
whole lot where in the data file the data actually lives as long as you have
enough room to place it in a physically contiguous fashion.  There are two
ways to do this.  One is to BCP out all the data, truncate all the tables
and then BCP them back in one at a time.  Preferably in the order of the
clustered index for that table.  While this does not guarantee it is
completely contiguous it does give the best chance that the data for each
table will be close.  The other is to rebuild the index with DBREINDEX.  In
order for this to work properly you need a lot of free space in the data
file so it too has the best chance of being contiguous.   When you shrink
the file sql server moves any data that is near the end of the file to an
open spot near the beginning.  There is no consideration for keeping the
tables contiguous on disk and they will get fragmented in a very bad way.
This has NO bearing on what the disk defrag tool sees at the file level.

OK now to answer your original question a little better.  Shrinking the file
does not compact or change the fill on each of the pages.  It simply moves
them to another physical location in the file.  So when you shrink a file
you will most likely end up with just as much data as when you started give
or take some.  How much usable free space you end up with depends a lot on
how much free space there was to begin with, where it was and how fragmented
etc.  It's not a pretty operation and not exactly predictable down to the
Byte level.

Hopefully that answered your questions a little better and gives you some
more insight on this process.