The main use case for ADFS in its current, initial release
is for interop between different authentication realms, such
as the forests of two corps, where the objective is to provide
webservices one to the other or both to each other, but, and
this is key, where the authetication and authorization to use is
unrepudiatable responsibility of the using realm once policy has
defined what the used party agrees to provide and the parties
agree on how those services are accessed.

Long words.  If I agree to provide services X to your users,
but I do not want to define accounts for your users, nor to be
responsible for authenticating that your users are who they claim,
and I want you to be responsible for your use of the provided
service, of the accounts you allow to use them, etc. so that I can
hold you responsible for the uses made by your access, then
ADFS fits the bill like little else can.

This use model is probably overkill for the cases you have described.
I can see how with an ADAM install on the machines without AD,
and providing them with an STS install, you feasibly could squeeze
the scenarios you mentioned into an ADFS model.  It would however
be pretty complicated for what it accomplishes.

Also the present form of ADFS is that it is for web scenarios
exclusively, and, when used in a domain does not need to be
installed on the domain controllers.