So here's what I'm hoping to find out: Is this code idiomatic modern C++?

Pretty much.
You use recursion to handle the multiple arguments. But a better technique may be to use the compiler to build objects to handle each argument. Unfortunately the way you have to defined the interface makes this a bit hard. If we re-consider the interface to make it like C-scanf.

template<typename T>
int parser(char const*& format, char const*& value, T& value)
{
     // Parse format and value.
     // convert the first % in format into value and save in value.
     // return 1 if value was correctly parsed otherwise 0
}

template<typename... Args)
int tscanf(char const* format, char const* value, Args&... args)
{
    // This will call parser() for each argument.
    // Each of the parameters inside {} are guaranteed to be constructed
    // left to right.
    // Because the compiler knows the number of arguments you
    // get a fixed size array that can be used to count the
    // number of parameters that were actually found.
    auto count[] = {parser(format, value, args)...};

    // Probably need a check for unmatched format parts.

    // The return the number of format parameters matched.
    return std::accumulate(std::begin(count), std::end(count), 0);
}

Am I overlooking useful features in the standard library that would make things easier?

I don't think there is anything you absolutely need.

Should I be using pointers in this way, or am I thinking too much in C?

NO. Absolutely do not use pointers like that.

Prefer to use references. This way you don't need to check for null. You also express your intent much more clearly so there is no confusion on the ownership of the pointer.

Should I consider another approach entirely, like tscanf(format, paramname1, paramname2) >> param1 >> param2?

There have been a couple of attempts like this. boost::format springs to mind. They used % rather than >>. But personally I don't see a need for this. BUT big advancements have come from trying the non obvious (things I would not think of). So please experiment.

Bug

There is at least one bug I noticed: if format is shorter than the number of arguments minus 1, you'll only detect this when scanning the last one, where format will point past the end of string.

Interface

Output parameters

The tscanf interface is not uniform for all supported types. Some arguments (bool and int) are passed by pointer, while other types (SomeStruct and everything else) are passed by reference. The user will find this confusing.

Some style guides (most notably Google C++ Style Guide) recommend using pointers for output arguments, since it is more explicit at the call site these arguments get modified inside the function. However, whatever you chose, use for all types.

Return and error reporting

The tscanf return a boolean indicating if the scan was successful. If you want to make it more compatible with scanf, it should return the number of correctly parsed arguments. However, since the format and parameters are not scanf-like, maybe it doesn't make too much sense to follow the return of scanf.

Since this is C++, not C, handling errors could be accomplished through exceptios. Consider throwing std::invalid_argument (<stdexcept>) or something like this instead of returning false.

Also, I'd expect a function like this to not write to any output stream (cerr in this case), but let the function user to report the error in the most appropriate form for the application.

Implementation

String length

Using std::strlen to check if the string has only one character is not very efficient, since the string could be very long. You could just check if the next character is '\0'.

In order to do this and also fix the bug above, I'd suggest to verify if format[0] != '\0' before all calls to the next tscanf and in the base of recursion to check also for format[1] != '\0' instead of calling tscanf.

Base of recursion

The code will become slightly more simple and less duplicated if the base of recursion is for zero arguments, instead of one:

bool
tscanf(const char* format)
{
    return format[0] != '\0';  // or throw...
}

This way, the case for one argument is the same for multiple arguments and you'll always look at the first character of format, even to detect if the string length is correct.

The only thing that will change for the user is that tscanf(str) will work (and only assert str has zero length), while your current version doesn't compile in this case.

Function template specialization

The assign function uses function template specialization, but that is uncommon (there are rare cases where it is useful) and not needed here. The usual way to specialize a function for different types of arguments is through overloading. The multiple assign functions could be declared this way:

template<typename T> bool assign(const char c, T& ref);
bool assign(const char c, bool* ref);
bool assign(const char c, int* ref);
bool assign(const char c, SomeStruct& ref);

This is already done correctly for tscanf function: both versions are template, but one is not a template specialization of the other.

Questions

• Is this code idiomatic modern C++?

  I think it is. Unless maybe for returning a boolean to signal errors instead of exceptions.

• Am I overlooking useful features in the standard library that would make things easier?

  I'm not aware of any standard library feature that could help in this case.

• Should I be using pointers in this way, or am I thinking too much in C?

  Pointers are part of C++ too and I don't see any case where they are being used without a good reason. Just avoid mixing pointers and references for similar things when both are right, as I said before.

• Should I consider another approach entirely, like tscanf(format, paramname1, paramname2) >> param1 >> param2?

  That is very subjective and I don't have any strong opinion about it. I particularly don't like the << and >> syntax from streams. In tscanf case, this would place the names away from the variables, which I consider worse. Maybe passing format string characters separately, each one just before the parameter name, may be better.