Your question is actually quite broad and touches upon a number is issues but the good thing is its all related to backlog items in one way or another.
I'm trying to understand the following problem: within a SAFe
framework a development team adds user stories after commitment, even
though that commitment has not been met. The justification is that if
these new user stories are not completed, the larger epics/features
will be endangered.
Regardless of Framework, user stories should always be prioritized and selected by the product person/team based on business priority. User stories are broad in nature that ideally have INVEST properties. Having said that, during the planning meeting, the development team can by all means influence the product/business person/s to select some low priority requirements for technical reasons. So the question is, why did the development team not bring up this "larger epic" related reasoning during the planning meeting?
Nevertheless, keep in mind that the development team is free to add, remove and edit their own technical tasks to meet the iteration's goal. Also, it is normal for the team to negotiate, during the iteration, with the product people to do changes to the stories. However, IMO, there is something wrong with your planning meetings if this happens often and affect more than a handful of the stories.
As a side note, this team spends an excessive amount of time planning
during Iteration Planning.
You should ensure product refinement is done and experiment with bul**** buzzer or simply a timer like the one below by putting it up on the big screen: http://oss.jahed.io/agility/timer.html
My question is: Should these new user stories be counted as tasks?
User stories are different from tasks. As mentioned above, user stories are written by or with the product people. Tasks are detailed activities that must be completed to complete a particular user story. Tasks are generally written by or with the developers. They are even written in different formats and styles. You can call user stories and tasks whatever you like, as long as you understand the difference (seriously though, don't come up with any new names for backlog items).
My confusion is around the principle of "just enough to start" during
iteration planning. As in each story should have just enough
information for team members to start working on them. If during the
course of the collaboration, new dependencies or work is uncovered,
does that constitute a new user story?
Just enough or emergent work are key agile concepts that minimize wastefulness and increase a team's focus on delivering the most valuable items first. However, this does not mean the developers start without a detailed plan. Along with backlog refinement, also read about Definition of Ready (DoR). The basic idea is that the backlog items that the product person/s want done during the next iteration are detailed enough and meet the DoR agreed by the team. Having said that, keep in mind that the team will not be able to decompose every single user story during the planning meeting. They should decompose enough stories for the first few days. Rest of the user stories will be decomposed regularly as the sprint progresses. Make sure the next most valuable user stories are already decomposed and ready for implementation before the current user stories are completed. Imagine mini planning meetings taking place almost everyday depending on your iteration length.