I would take great care diving straight into being a Scrum Master, as you risk being perceived very negatively by teams. I am a Scrum Master who has come from a development background, which makes it much easier to fit in with the team naturally and not come across as 'management'.
There are three stages of Scrum Teams, sometimes referred to using Shu-Ha-Ri; a martial arts term. Your background will mean you fit into teams in some of these states much easier than others.
In the 'Shu' (Obey) stage teams are learning the fundamentals. This requires more of an enforcement attitude from the Scrum Master, and is where technical knowledge would be most useful. This is where teams are likely to be creating their 'development best practice' - so to me the scrum master should be enforcing code reviews, helping to implement XP or whatever approach the organisation are taking, and suggesting (often technical) additions to the definition of done. This is where many 'Scrum Consultants' (who are often not technical) seem to be failing the industry to me - they bring in 2 week sprints, self organised teams, and backlogs, but do not address the most important part - the underlying development standards that Scrum was built and relies on. Most teams never leave this stage, and this is where Scrum Masters who are not technical are really hurting the industry.
The next stage teams reach is 'Ha' (Digress) where they are working as a good Scrum team, and start to understand why they are doing things, rather than just following the process. This is where the team have the basics down and are working as a good team already. At this point they must have good development practices in place, so a Scrum Master who is less technical could probably get by. The team is motivated to keep up their technical excellence, so the Scrum Master doesn't need to be driving this, but might want to keep reminding the team to keep up their technical excellence. There is still a risk development practices could slip and the team not notice, and without being technical a scrum master may never know.
If you get the rare chance to work with a team at 'Ri' (separate) who is hyper-productive, I don't think you need to be technical. This is probably the best sort of team fitted to your situation. Your psychology background would probably make you better than most Scrum Masters at really getting to the bottom of deep, hidden issues that many Scrum Masters might miss, so you may want to try to specialise in working with awesome teams that are trying to etch out additional improvement. This is where teams are coming up with their own ways of working, maybe abandoning Scrum all together.
I have a software development background, and have led multiple organisations through the Shu and arguably Ha stages - often after agile consultants have already done a lot of damage by bringing in Scrum without any consideration of the development practices it relies on. If you are involved in agile adoptions, ensure to work with a development manager or senior developer to put best practice in place BEFORE bringing in agile. Without this, non technical Scrum Masters can seriously break teams and organisations. You can do it, but the more technical knowledge you can get the better.