My question is this: to what extent should I try to incorporate these tools into my research code?
Only as much as you feel will pay off for whatever you're trying to do. If you're mostly doing MATLAB scripts, version control and maybe unit testing are going to be all you need. If you have MEX files, it's probably good to have a Makefile that compiles them, if only for your own sanity, since typing in sequences of compile commands each time you want to build the MEX files is fragile.
Part of the reason these workflow tools get used and incorporated into large projects is because the investment in these tools pays off for their goals. As an example, for one-off research code supporting your thesis, it's probably not worth using a cross-platform build system like CMake. For a library whose stated purpose is to be cross-platform compatible, like, say, Elemental, it makes more sense to invest time in using a cross-platform build system.
How much time should I spend "planning" the structure and implementation of my code, or should I stop thinking about it and just write good routines?
It depends on how familiar you are with the problem you're trying to solve, appropriate algorithms, data structures, programming practices, and so on. Much like outlining and prewriting are helpful for journal articles, a certain amount of brainstorming and pseudocoding is helpful for writing well-structured code. I like the Pseudocode Programming Process in Code Complete, by Steve McConnell; he also includes some references and guidelines in terms of how much time should be spent on the design phase, depending on the type of project.
Writing throwaway versions of routines and experimenting with short bits of code is also really helpful. A common aphorism in software development is that you'll always throw away at least one version of your code.
I tend to believe that "agile" development practices tend to work best with most scientific software development, based on Greg Wilson's work at Software Carpentry (disclaimer: I have volunteered with them in the past). Broadly, "agile" means you should set goals you think you'll reach in a short period of time (say, a couple days, a week, maybe a month at most), plan out how to reach those goals by doing some pseudocoding and designing, and then write code, and repeat. Short cycles will help you react to changes, such as when your adviser decides that he wants you to extend your work in ways you haven't anticipated.
I feel as though I should be developing a well planned open source code base as a product of my dissertation, for the experience and CV cred, but I'm not sure how to navigate this process. Any tips, book/article/website recommendations, etc?
That all depends on what you want to do. For positions involving software development, developing an open source code base is helpful, because it's something you can post on GitHub and point to. That said, if you want to make it a software package people will use, you're going to have to spend some time maintaining it; you may not want to do that. Contributing your research code to relevant existing projects can also be a really good option. Companies seem to want a mix of both. If you can contribute to other people's code, it shows you're a team player and that you can read other people's code and still do something useful with it.
In terms of references, Software Carpentry's reference reading list is well-geared towards scientists, and if you want to dig deeper into software engineering practice, Code Complete (see the list in the previous link) has further references that are starting to become a little dated, but are useful to look up. The papers they put out on best practices in scientific computing are also helpful
Software Carpentry's lessons are helpful, too. They're Python-centric when it comes to programming, so you might take that with a grain of salt, but the version control parts are worth looking at.
