Tips For Retro Action Items?

Should you try to create an action item for every 'didn't go well' item or is the venting enough?

Neither.

If you have a lot of things that didn't go well or could have gone better, and you probably will always have several of those, you shouldn't try to tackle them all and you should do a whole lot more than vent.

I'd recommend trying to narrow down to one or two things that had a significant impact and are likely to happen again. Then, focus on coming up with ways to prevent it. You don't necessarily need to do all of the solutioning within the Sprint Retrospective. Take it and work on it throughout the Sprint. Brainstorm and think about ways to change your way of working, experiment, and try to do better so the problems are going to be different problems.

feel like my team often discusses things that did not go well, but they struggle to come up with 'SMART' action items.

Why? Which of the SMART criteria are they struggling with?

If your teams are like the ones I've worked with creating an action item for every "didn't go well" would result in more action items than there are items in your Product Backlog for product changes.  

Improvement is an incremental thing best done with experimentation.  You change 1-2 things at a time.  Stay with those changes for a while to see if they were the right changes to make.  Constantly inspect the area that was changed looking for new information.  Then adapt as the new information is found.  Let empiricism show you the way.  

Also, it is often found that by changing one thing that is the most troublesome will also remove some of the less troublesome things because those are often being done to compensate for the big thing.  

What I usually do is have the team discuss what went well and bad during the Sprint.  Capture everything that was said.  Let them all come to agreement on the two things that went well so that they can continue to do those.  Then have them agree on two things that went bad that they would all like to address.  Come up with a plan of action for those two things.  Then everything that was captured during that Retrospective is destroyed, deleted, shredded, etc.  Each Sprint is unique so things that was bothersome in one Sprint may not be for the next due to the work that is being done.  If you work on two good, two bad each Sprint, over time you will be making improvements. But you will never completely be rid of the process.

Retrospective means -

What went well - which we want to retain further

What we need to improve - in upcoming sprints, gradually

What we need to drop - immediately or gradually depends on situation

What we are lacking - identifying ideas, tools, methods to enhance team towards self organizing

Focus need not to be just to have action items, sometimes team can pat themselves for better work, better collaboration.

If a sprint is of 1 week or 2 week, every time getting 1-2 action items will be like expecting too much from team.

For teams in norming, forming stage action items can be found with the help of scrum master (may not necessarily always). However mature teams action items won't come up in every sprint.

Retrospective is evolving process, gradually.

May be you can see if DoD, DoR can be modified. If some more refinement session, team collaboration activities are required.

Set the expectations right, don't run behind action items always. Sometimes appreciate things and work on retaining good practices also.

Focus on constructing self organizing teams, which reach performing ladder of team stages.

Should you try to create an action item for every 'didn't go well' item

You can not. Go for voting of the item which team thinks that is to be acted upon immediately to improve in the upcoming sprint. Try 15% solution to get a buy in from the team before they leave the retro(https://www.liberatingstructures.com/7-15-solutions/). Add that improvement point in next sprint backlog or DoD can be modified if required. But still they have tendency to oversee it because not all team members are motivated all the time. Some developers feel retro is not worth the time spend because they seen nothing changed or some take it as fun event. So that mindset will change only when the action items are really experimented and outcome is discussed in the next retro.