Generally, it's an organic process for me.
My namespaces tend to mirror my folder names, primarily because I think it's easier to find things that way.
Corporate projects generally have a company prefix in front of the namespace, and for personal projects I toggle between project-prefix.folder and just folder for the names.
The "main" folders tend to be obvious for their name, and are generally related to their function - "Foo". For larger projects, I'll break out the main folder to reflect the major programming paradigm I may be following. So for MVVM, I would have "Foo.View", "Foo.ViewModel", and "Foo.Model" as example names.
Invariably, helper functions that don't fit anywhere else start to creep into the project. I'll start with a "common" or "utilities" type folder to first land them. "Helpers", "Base", and "Core" would work just as well for an initial landing place.
I try to name my functions based upon the Subject and / or Action that they perform. So I could have a PathManager, PathChecker, etc... Oftentimes, I know I'll have several Actions related to a subject, so I'll name the class after the Subject and add methods as needed. A thesaurus can come in handy here.
I have found a high correlation between ease of naming an object and how well I can describe what the function is supposed to do. One of my personal checkpoints is that if I'm struggling to name something then that means I need to reflect upon what the function is actually supposed to be doing. Once I fix the functionality issues, the name comes easily.
As I gather more helper functions, I'll migrate them to their own folder and / or namespace. Whether they get a folder off of the root project or whether they get a sub-folder to the utility folder depends upon the nature and quantity of the functions.