I just finished building a massive SharePoint feature that provisions a list, adds a web part to a page, installs a workflow, associates that workflow with the list, adds settings to the web.config and encrypts them, and then makes you a sandwich when it's done.
This workflow is automatically kicked off when an new item is added to the aforementioned list. Now I don't know the details here, but it seems as though the first time a workflow instance is kicked off, it adds a field (with the same name of the workflow association, of type hyperlink) to the list that takes you to the workflow tasks for the instance.
However, it only adds this field to the default view. This is a bit annoying, and like I said, I don't know the details, so I don't know if you can turn this off or change it somehow. So, being the stubborn SharePoint guy that I am, I went ahead a did it myself. :)
The SharePoint code I'll share below is fairly straight-forward. The challenge was determining when and where to execute this code. Since we are (apparently) abstracted as to when the workflow creates this field, I had to figure out the right moment I would have programmatic access to it.
The answer is in the "onWorkflowActivated_Invoked" event of your workflow. At this point, the list item for this instance has been created (since this is what activated the workflow) and, after checking the columns in the list at this point, I found that the workflow field was indeed in the list. So all we have to do is add this field to any views we want.
In my case, I wanted it on all views, so the logic is more trivial. Here's what to do:
(Quick note on field internal names: they are not necessarily intuitive. For Example, "field name" will be something like "field_x0020_name" internally. Also, for these workflow fields, the system will generate the internal name. For example, a workflow association I created was called "Timesheet Approval" and then internal name of the field was "Timeshee" - so be careful! It might be worth your time to write a quick bit to dump the internal names of your list into a text file for reference.)
I know this might seem like a lot of work to do for a pretty specific result, but if you are creating SharePoint features, you need to provision everything precisely the way you want it. Since things are easy to customize out-of-the-box in SharePoint for end users, there is going to be very little patience for "sloppy" features.