Yes, this adds the authentication token for a logged-in user.

get_list returns a list of the names of all of the hosting services. I'm not sure what would GETing an item return? What infortmation should be provided on a hosting service, given its name?

Each item should basically contain the same contents as an item in the list returned by get_list.
So, if get_list returns:
'hosting_service_accounts': {
    'items': [
        { <payload1> },
        { <payload2> },
    ],
    ...
}

Each item would be like:
'hosting_service_account': {
    <payload>
}

Check out other resources to see how the lists and items differ.
Basically, every item in a list of resources should be able to be retrieved independently, at a stable URL, so that's what we'd need to provide here. Usually this would all come for free, since most resources are dealing with database objects and all that stuff is automatically done for you, but for custom things like this, you need to do it yourself.
(I super want to improve this in the Djblets webapi code to be more generic and allow for making usage of more custom payloads easier.. Hey, you wanted a new project, right? ;)

I understand the general principle, but in the specific case of list_items returning only the names of all the hosting services, given a name of a hosting service, say, 'github', what should the paylod be? The name of the the class, i.e. GitHub?

The payload for both the list items and the individual resource should be detailed enough for a new JavaScript interface to have all the info that the Python code currently has, so I'd suggest they both contain at least the following:
{
    'id': <name>,
    'plans': <plans dictionary or null>,
    'supports_bug_trackers': ...,
    'supports_...': ...,
    'needs_authorization': ...,
    'supported_scmtools': ...,
    'repository_fields': ...,
    'bug_tracker_field': ...,
    'links': {
        'self': {
            'method': 'GET',
            'href': <absolute URL to the individual resource>
        },
        'remote_repositories': {
            'method': 'GET',
            'href': <absolute URL to your HostingServiceRepositoryResource list for this service>
        },
        'accounts': {
            'method': 'GET',
            'href': <absolute URL to the HostingServiceAccountResource list for this service>
        }
    }
}

Should HostingServiceAccount then be a child resource of HostingService?

Also, based on another comment, remote_repositories is a child resource of the account, so I'm not sure how would I get the links without the account.

services is a generator over name, cls in six.iteritems(_hosting_services)

Oh oops.
In that case, just change the formatting like above. Makes it a bit easier to read when it's on multiple lines, and more consistent with more of the codebase.

Given that the get_list returns a list of HostingServiceRepository objects that are created from a call to a remote API, what should GET item return? The HostingServiceRepository objects are not stored anywhere. Should this call get_list, and then search through it to return the one repository that was requested?

I think what you should do is have get_list and get both call self.serialize_object on each HostingServiceRepository instance, and have that function handle serializing it to a dictionary.
get_list would then just iterate over all of them and serialize into a list, while get() would just grab the appropriate one given the values in the URL and serialize just that.
You'll want the formats of both to be consistent with what a DB-backed resource would return. (Links and ID and stuff.)

The reason for doing this is so that I can replace the call to this function with call to _get_remote_repos in the tests to avoid calls to third-party APIS. Please let me know if there's a better way to accomplish this.

Oh I see.
So, our older tests are just replacing the function on service directly. However, we have this awesome module now called kgb that is designed to safely override functions.
In your tests, you'd do:
self.spy_on(service.get_remote_repositories, call_fake=_my_get_remote_repositories)

And then, any time something tries to call service.get_remote_repositories, your function will be called instead.
See https://github.com/beanbaginc/kgb

I am using kgb =) But I can't replace the function on the service object, because the service object is creted within the API call based on the name of the service that was requested. That's why I have the extra function in the API - in the tests I replace it with a fake call.

I think you can still replace it on the class itself before the call, can you not? We've certainly done this elsewhere.

I tried replacing it on a class, but that only worked if the method was a classmethod.

Is there an easy way to associate an object that's not a model object with the API?

So far the best I can come up with for serializing is:
repos = self._get_remote_repositories(account, plan, service)
repos = [
                {self.item_result_key:
                     self.serialize_object(repo, request=request)}
                for repo in repos
            ]

While the HostingServiceRepository isn't technically a Django model, you should still be able to register it like one, just like we do elsewhere. resources.py should be able to register it to this resource, and then you can provide a custom serialize_object() that properly serializes all the fields we want on it (which won't be __dict__, it'll be all the fields we'd need to identify, represent, and later map to a Repository).

We definitely need errors returned in the API if we encounter them.
However, that code has some issues that I'll want to point out separately, which will help clarify this question.

HostingServiceRepository is not associated with a model, and trying to serialize it throws AttributeError: 'HostingServiceRepository' object has no attribute 'pk'