This is a partial answer as I can't really help with 'how can my Working Copy be in conflict with a brand new branch created from my Working Copy?' with the info available. I'm not sure exactly what's happened but you've tried to commit two logical changesets (a new branch, possibly not even from HEAD; plus uncommitted work) as one, which isn't a great start. See Subversion Best Practices.
To cleanly make a branch of trunk with uncommitted changes and without using the repository browser I would first update my working copy if it is not up to date with trunk. Then svn copy a clean and updated copy of trunk into my branches folder (which I keep checked out) and commit the branch. I'd svn update if there any externals. Alternatively, I'd branch from trunk in the repository browser and check the branch out.
Then I would delete (not svn delete) everything apart from .svn in the branch, copy and paste the current working set into the branch, fix any renames and moves to retain history ("repair move" is now available in the tsvn commit dialog to help with this), and commit the changes as a seperate operation.
To answer the question 'Can I safely mark the conflicts as resolved and "Keep the local file" (in the case of "files added locally" conflicts) without fear of losing history?' then it is a qualified yes, provided all of your work was committed (see the svn log) all you are doing is cleaning up a working copy. However, to be safe, I would rename this working copy and put it to one side. I would then cleanly check out a new copy of the branch and resume my work there. Since we are not 100% clear on what has happened here I would emphatically be taking the safe option.
It may also be advisable to test merging the new branch back to trunk right now, as its not impossible you will have a world of pain when you come to merge it back. If the test merge fails you might want to branch again, ensuring you are starting the branch with a clean unmodified up to date copy of trunk.
