It is common for languages to have namespaces or packages but where the packages can't themselves be used as values in any way. Standard ML and OCaml allow packages (structures) to be used as values as functor arguments.
F# has structures - like Caml each file denotes a structure, but they cannot be used as values, and cannot currently be nested, structures can't currently contain structures. There is no particular reason why substructures aren't implemented except that in my personal optinion they are not as useful as people think except when writing very large frameworks like the .NET framework or the Java class libraries. F# is currently aimed at writing 100-50,000 line programs that either define .NET assemblies or access other assemblies. For this kind of programming, which ML is very suited to, you can get away without writing substructures.
You can access nested .NET namespaces using long identifiers (System.XML.XmlNodeList), and no doubt substructures and/or subnamespaces of some kind will be added to the language proper at some point. However I don't plan on sending F# down the functor rat-hole.
To answer your other question, SML.NET will be released soon. The great thing about .NET is it just doesn't matter if you have more than one language implementation: you can quite easily share modules across langauges. The main purpose of F# was to work out parts of the cross-language functional programming story in a slightly simpler setting than full SML. In particular, F# concentrates on making all ML constructs be accessible from other .NET languages, and on a simpler tool/compilation story. These things are hard to retrofit on a project like SML.NET which has a large whole-program compiler and a more complicated (but in some ways more expressive) surface language. Now we've worked that out it's equally likely that we'll transfer the results back across to SML.NET and you'll be able to access all SML constructs from .NET languages as well. Eqully we might use SML.NET's whole-program compiler backend for F# and some point, depending on need and resources available.
So, F# or SML.NET- it doesn't really matter: choose one and get going with .NET programming - it really is good fun to suddenly have access to all these libraries and web services!