Before I dig in, I'd suggest that in your question when you comment "It can be done by arranging several meetings and working on the subject", you're actually headed in almost the ideal direction. No approach to working through problems with larger, fuzzy things that need built will be successful without facilitating the right conversations at the right time. These do NOT have to be "meetings", and should be focused on the right people being involved, often 1-on-1 or small group in the team room as the work is being done.
Otherwise, I will typically come at this from two directions.
First, recognize that stories typically take longer for one of three categories of reasons, and thus derive higher story point estimates as a results. Those three categories are complexity, effort, and doubt. Complexity is the "We've got to figure this out" bit of the work, effort is "we know exactly how to do this, but it still takes time to go through the steps" and doubt is "we don't know how we're going to do this.
Second, I've observed that giving people a framework within which to decompose stories can often help immensely when they're working. Engineering types LOVE to create new approaches and processes, and that can be highly distracting from the effort to figure out how to approach the epic. As a result, I tend to suggest something like Dean's Epic - Feature - Story - Task decomposition model to organizations that are tying to coordinate many teams, while only using Epic - Story - Task for single teams or smaller organizations that don't need the extra complexity. The framework may not be ideal, but most work I've seen fits into it rather easily and it does provide a useful model for teams to get focused on their work.
Now, using those two perspectives, I'm able to work with teams to isolate the uncertainty. During release planning or backlog grooming time, the next large epic can be split up to understand which features are included and important (some teams just call these "child epics" instead of features). Each conversation around a split will indicate some things that are obvious, but hard (high effort), some that need figured out but are definitely possible (high complexity), and a few things that we're not even sure if we're headed in the right direction or if it's possible (high doubt). The relative value of these things can inform if you need to attack the doubt items first (because you might cancel that part of the app if it can't be done) or ignore them altogether (because you realize they're not important), while the complex items can be handled by planning time to have the right conversations just in time. High effort items just need done, and can occasionally be outsourced easily.
Having this understanding around each of the stories and features going into the work allows the team to focus on the right aspect at the right time.
The other part of your question seems to be "According to Scrum, when do I do this?"
In most implementations of Scrum, the team will need to spend some of its time assisting the product owner in grooming the backlog to the right level of detail. Most if not all of this time should be focused on stories that will be implemented in the coming sprint or two, as the learning from the conversations will fade quickly.
Conversations needed for complex items should occur just in time, during the sprint if at all possible (which is one reason Scrum requires a highly available product owner). Conversations around high-doubt items will need to occur earlier so that everybody understands exactly what is doubtful and what the decision points will be as the team attempts to resolve it. Many teams use spikes for these high-doubt items.