Well, the class name is generic because it hasn't been properly extended (or by a restriction in Python); there's nothing generic about the code in this class.  It should not be called command, unless it has to be.  Perhaps GenerateFakeDataCommand?

Also, what you find awkward, I find totally natural.  I find unbound (global) functions to be really awkward, especially when mixed with classes.  Mixing OOP and non-OOP in the same file... just semantically, I don't get it.  It's really ugly to me.  Instead of your example, I think the natural import/usage is:
from ......generatefakedata import GenerateFakeDataCommand as genfakedata
genfakedata.generateFakeFacilities()


A great example is my branch for SyncingModels.  There, there were a bunch of objects and some floating methods.  Some of the floating methods were logically related to each other, and used global data.  To me, they should all be encapsulated--either as a separate file/module, or as a class with static functions.  I find the importing and usage of the static class to make a lot of sense:
from staticsync.models import SyncingModels
SyncingModels.add(xyz)

not so different to me than the previous:
from staticsync import models
models.add_syncing_model(xyz).

Except the former has meaningful encapsulation, the latter doesn't, to me.  "Models" is really weak encapsulation for that method.


Anyway, I can see going with the python convention for this case (since the file itself is very specific to the fake data generation, so mixing module and class as 'encapsulation' seems ok), but I think in cases with more generic files (models.py, encapsulating related functions into classes is semantically really helpful.

Perhaps we can chat about it next week, re: SyncingModels (I'm sure there's other stuff to discuss with that code, anyway).  Glad to hear some thoughts (feel free to be brief; I'm kind of thinking out loud here).  I can make the changes for here!