Here's a step-by-step walkthrough on how to autocreate a node reference using the Autocreate Node Reference module.
First, please make sure the official Node Reference doesn't do what you need before choosing ANR. If you're referencing the same existing node from numerous other nodes, use Node Reference. ANR makes a new referred node for every new referring node, and you really don't want to do that if you don't have to.
OK then? I'll use a simple possible common usage, adding a 'Was this article helpful?' poll to every node of a certain type. Preliminary instruction: make sure you have Poll enabled in admin/build/modules.
1. Config settings
Go to Administer > Site configuration > Autocreate nodereference. Here is where you set the template token that will identify nodes you will be using for autocreation. If you don't want to use 'AC_TEMPLATE', change this to whatever you want and substitute that for 'AC_TEMPLATE' for the rest of this doc. This is also where you set suffixes that will be used for autocreated references. So, scroll on down to the suffix field for Poll. I'm going to have you use 'Poll' as the suffix for a Poll in this example because I'm very creative. ;^)
You're done here, so save your changes and proceed to Administer > Site configuration > Clone module and see that 'Reset publishing options for Poll' is unchecked.
2.x (and D7)
You're right, it's not a Poll field, it's a fieldset with a checkbox that says 'Reset publishing options of cloned node to defaults'. See that it's unchecked.
2. Create a template
Now you need a Poll to clone, so go to Create Content and make a new poll asking the question 'Was this article helpful?' with whatever responses you like. Continuing the creativity displayed on the config page, let's call it 'Poll 1 AC_TEMPLATE'. Because this is just a template node and you don't want users to see it, uncheck 'Published' and 'Promoted to front page' under Publishing options.
Very Important: Make sure your template node title contains the string you've specified as your template suffix in step 1, whether it's the default AC_TEMPLATE or your own chosen suffix. Without the suffix, ANR won't find your template(s), so they won't show up in the select list when you go to add an ANR field.
3. Adding an ANR field
With your Poll all set up, go into 'Manage fields' for the content type you want to add a poll to, and add an Autocreate Node Reference field (labeled Node Reference (autocreate) in 5.x).
In order to successfully autocreate a reference, your field name must be exactly the same as the machine-readable name of the content type you're referencing in your ANR field. No creativity here, what you will enter for the field name is 'poll', or things just won't work. (If you're referencing some other content type and aren't sure of the name to use, find it under the 'Type' column on your Content types admin page.)
As of 7.x, you can name your field anything you want. You can even have multiple references to different templates of the same content type.
On the field configuration page for your new ANR field, scroll to the Global settings section and select the template you want--unless you have another node with your template token in the node title, your Poll template should be the only option at this point--from the 'Select template' list.
Very Important: Unlike most other node reference fields, ANR is intended to create just one reference per ANR field, so your Number of values global setting needs to be 1 or you'll end up getting PHP errors when trying to post your content type.
Save field setting, save your type, and you're done.
4. What will happen
Now, when a user creates new content (let's say they call it 'Best Post Ever') using your type, the ANR module will make a clone of 'Poll 1 AC_TEMPLATE', name the clone 'Best Post Ever Poll', and put a link to 'Best Post Ever Poll' in the 'Best Post Ever' node. The 'Poll: reset publishing options when cloned' settings will set the 'Published' and 'Promoted to front page' settings for 'Best Post Ever Poll' to the defaults for Polls. When 'Best Post Ever' displays after it's been submitted, a drupal message will contain a link to the edit page 'Best Post Ever Poll'.
The 6.x version has an unfortunate reliance on the title of the referenced node. So, 6.x users can edit the content of the referenced node, but changing the title could break things.
7.x does things the right way and stores the nid of the referenced node, so title can be changed without breaking anything.
5. Publishing settings
You may or may not want an autocreated node to be published and/or promoted when it's created. For most of the clones you might autocreate, unpublished is fine because users can get to the cloned node via the node reference. But there are times when you might want something else.
I'm using ANR to create references to both an Organic Group and a webform associated with a node--I only want users accessing the webform via the referring node, but I want the group published so it will be listed with the rest of the groups on my site. So for defaults, I have 'Published' and 'Promoted to front page' off for webforms, and 'Published' on for my OG group node (I don't want groups on the front page). For webforms, 'Reset publishing options' is basically irrelevant, while for OG group nodes, it's on so that when I clone my unpublished group node template, the resulting clone is published. You may need to tweak Workflow defaults and 'Reset publishing options' settings for nodes you want to autocreate, depending on how and where you want them to display.
Caveats and LImitations (6.x)
Field names are global. This is a really cool thing for creating Views and being able to share data across types. For ANR and our example here, however, it means that field_webform will have the same value for every content type that has a field_webform, so all types with a webform reference will clone from the same template. But what if you want to have a reference to one webform in one content type and a different webform in another content type?
This is a limitation in 1.x, but 2.x lets you include the referring content type in the field name. E.g., given two content types, my_type_1 and my_type_2, and two different Webform templates, WF 1 AC_TEMPLATE and WF 2 AC_TEMPLATE, my_type_1 can have an ANR field called 'field_my_type_1_webform' that uses WF 1, and my_type_2 can have a field called 'field_my_type_2_webform' that uses WF 2. Or, if you find the idea of numerous webforms to be a bit of overkill, you can just stick with 'field_webform'--for backward compatibility, it is not necessary to include the containing type in the field name. 2.x does still have the limitation that you can only reference one instance of a type from within any other type--i.e., in my_type, field_my_type_1_webform and field_webform are equivalent.
A D5 limitation is that variable names, including field names, can only be 32 characters long. 'field_' counts as 6 of those, leaving you with 26 characters for two content types in your field name. This means that if you have a content type with a long machine-readable name like 'notice_of_a_great_time', you're not going to be able to have a field_notice_of_a_great_time_webform, what you'll end up with is field_notice_of_a_great_time_web, which will not do what you need it to do.
ANR lets you create references to nodes of any content type on your site. Most of the possibilities are really quite useless if not ridiculous, but they're all there for flexibility's sake.