Add drush support

Heh. Turns out the file you give to drush can't be a single node, it must be an array of nodes.
Code as posted here works, except for the node uid which gets set to Anonymous, since this is what drush runs as. This could probably be fixed with a user_load() of uid 1, or a change in the module.

Updated version.
The drush command switches the current user to uid 1 so nodes aren't anonymous. Added help too.

My use case is a client who wants a new site every few months with the same set of about a dozen pages to start with -- about, history, contact us, a webform and so on.
I've been using bones modules for this, which takes care of menu structure and paths, but the content still has to be copied over.
However, with this module I can create the content quickly.
And with drush support, I can make this another step in my drush install script:

drush dl (modules)
drush enable (modules)
drush node_import < datafile

Site done! :)

To answer your other questions:
- it probably makes sense to take the gui options. Drush can take commandline switches, but your module's code would need changing to accept them, probably.
- export would be useful too I think; however I just needed import for now. I'm sure if you committed this someone would provide the export ;)
- I don't think it makes sense to put drush support in a separate module. Most modules that support drush do so by adding the drush inc file to provide drush support in parallel to the gui.

Good point about the namespace.
So:

drush node_export import < file
drush node_export export 45 46 47 > file

I don't think we need to distinguish between printout to terminal and to file -- that's what command line redirection is for:

drush node_export export              // prints to the terminal
drush node_export export > file    // prints to the file

As for settings, I don't think it's customary for drush module commands to let you change settings permanently. So I'd say skip that.
For setting import options at command time, drush takes options like --path, say.

The approach I took for module_builder was to restructure the module code so that instead of the function that does all the work doing variable_get() to find out settings, it has them passed to it as parameters. This means drush can check the command line options and pass them, and the GUI-based system can pass them in when it calls the workhorse.
This may not be the most elegant method!
The other option I can think of would be drush reading the existing variables, storing them, setting them to the values given by the command line, then restoring the originals after the command has run.
This is doable, again not hugely elegant, and if we were to implement this it might as well be in core drush for all modules to take advantage of -- say as a function drush_temp_variable_set() and drush_variable_restore_all(). Which might already be in drush, must go check ;)

I'll have a look at restructuring the drush inc to change the command names and give you a stub of a node export command.

On second thoughts,

drush node_export export 45 46 47 > file

means you don't see error messages, so we should add a file option too.

Updated version of the file with changes as outlined above.
I've left the calling of the exporting code for you to do, everything is in place, just turn the $nids into $data :)
Not looked at overriding settings yet: see #610372: system for setting temporary drupal variables.

Just found there's a stray closing bracket in the 'examples' key in the first hook.

Just to say I used the drush import on a site and it worked perfectly :)